Chez CGX SYSTEM, nous fabriquons du logiciel !

Mais, in fine, que ce soit bas niveau pour les firmwares des matériels ou haut niveau pour les applicatifs : nos techniciens écrivent du code.

Certes, nous paramétrons et installons aussi du matériel pour créer de la donnée depuis le terrain : positions GNSS, données des machines, saisies des opérateurs depuis les tablettes et les mobiles, capteurs, etc…

On peut entendre parfois “que ça doit pas être bien compliqué d’ajouter un bouton et de faire ceci ou cela”. C’est à la fois vrai et faux et cela dépend fortement de la qualité qu’il faut maintenir à l’ensemble de l’applicatif dans le temps.

On va vous en dire un peu plus ; on va ouvrir le capot ! 😀

Du code au programme

Vite dit, le code est un ensemble d’algorithmes logiques qui ont chacun une mission : recevoir des données en entrée, les transformer éventuellement et les transmettre à d’autres algorithmes.

Cela peut ressembler à :

“toutes les secondes, pour chaque dameuse dans le périmètre, si le moteur est allumé ET que la vitesse est supérieure à 0 ET qu’un dameur est actuellement connecté, alors envoyer une alerte à la tablette dont le numéro unique est X”.

Cette ligne de code serait une infime brique dans un composant plus large Gestionnaire Alerte dont la mission sera de détecter, émettre, traiter les alertes tout au long de leur durée de vie. Ce même composant peut être utilisé par d’autres composants : par exemple, un ObservateurGNSS qui s’occupe d’écouter et d’enregistrer les positions GNSS.

Il faut ensuite assembler tous ces composants dans une architecture claire.

En tant qu’utilisateurs, vous êtes familier d’un de ces composants : l’interface. On lit parfois GUI pour Graphical User Interface. En soi ce composant est lui-même un catalogue de multiples composants qui vont de la page que vous voyez, à des panneaux, des listes et des boutons qui la remplissent.

Soigner l’architecture

Dans tous les cas, il faut prêter une grande attention à l’architecture.

En somme, c’est le plan.

Il s’agit de la manière dont le code et les composants vont être organisés, et comment ils vont dialoguer ensemble. Il faut des responsabilités claires pour chaque composant. Un développeur doit pouvoir rapidement comprendre où trouver (ou bien où écrire s’ il n’existe pas) la fonction dont il a besoin.

Concevoir et élaborer un programme, c’est assez similaire à la construction d’un bâtiment.

Selon cette métaphore, il faut penser à tout en amont, avant chaque étape, pour éviter que le bâtiment soit un assemblage de bric et de broc. Il peut paraître simple de faire évoluer la construction pour atteindre rapidement l’objectif ; la tentation est grande d’aller à l’essentiel en « pliant l’existant » au besoin immédiat : ajout d’une fenêtre, d’un circuit d’eau entre deux pièces, d’une ouverture vers le toit, etc.

Mais, au fil du temps, de telles pratiques font que la maintenance devient complexe voire ingérable.

Pour en terminer avec les images, et pour l’exemple du circuit d’eau, il est peut-être préférable de concevoir et de réaliser des travaux plus complexes et plus génériques pour répondre au besoin.

Certes, ce sera plus long à mettre en œuvre, mais le résultat sera cohérent et harmonieusement intégré à la structure globale.

Demain, il sera question d’irriguer une autre zone du bâtiment et parce que cela aura été envisagé, la modification sera implémentée plus facilement et surtout sans « tordre » l’existant pour l’adapter de force au nouveau besoin.

Un cadre pour du code parcimonieux et clair

En résumé, penser et concevoir avant la réalisation est une étape fondamentale et préalable à tout développement logiciel.

Une bonne architecture est indispensable !

Avoir une architecture claire doit s’accompagner de blocs de code succincts, lisibles, chacun ayant une mission limitée et évidente.

Ce sera sûrement l’objet d’une future brève technique !

A très vite 🖐🖐🖐