La fin d'une mission, ou d'un projet, c'est toujours une bonne occasion de faire le point. Je viens de terminer tout récemment une mission de quelques mois en tant que développeur logiciel, en SCADE, pour un système embarqué sur avion. Cette mission a été plutôt enrichissante sur plusieurs points.
SCADE
SCADE est un environnement de développement propriétaire édité par Esterel, et basé sur le langage Lustre. Il cible principalement les applications dites "critiques", dans des domaines divers comme le ferroviaire, le nucléaire, le spatial... et bien sûr l'aéronautique.
Ce que les gens du milieu appellent un peu pompeusement de la "spécification formelle", j'aurais tendance à l'appeler du "codage graphique" (pour un certain nombre de raisons, les ingénieurs systèmes apprécient peu le terme "code"...). En effet il s'agit ici non pas de coder avec des fichiers textes, mais directement avec une représentation graphique (c'est cette représentation, qui se veut le pendant visuel de la spécification textuelle, que d'aucun nomme la "spécification formelle"). Par la suite, cette représentation graphique est convertie en langage Lustre (langage de programmation textuel, "classique"), celui-ci étant à son tour interprété afin de générer le code C (ou Ada, au choix) qui sera finalement executé sur cible.
Alors en pratique, à quoi ça ressemble ? Pour des raisons évidentes de confidentialité, je n'ai pas d'images de mon projet sous la main, mais en gros c'est un espèce d'hybride entre des représentations de fonctions logiques (notation américaine), de machines à état, et de certains schémas UML. Un exemple de chez Esterel ici (machine à état en haut,"workflow" en bas).
N'ayant jamais utilisé ce type d'outil avant, j'avoue que l'adaptation se fait assez rapidement, même si certains aspects restent déroutants (la représentation des machines à états est à mon avis assez peu intuitive par exemple), et si certains côtés sont un peu frustrants (gestion des types...).
Par contre, clairement l'outil possède des avantages sur du codage manuel normal :
- Tout l'aspect concurrent et synchrone est épargné au développeur, évitant de nombreuses erreurs
- Abstraction également de la gestion de la mémoire (ce qui n'est bien sûr pas le cas en C ou en Ada - de longues heures de debug gagnées...)
- Représentation du code sous une forme lisible par quelqu'un ne sachant pas coder (un ingénieur système par exemple)
- Annulation du besoin de vérification manuelle sur de nombreux points (revue du code généré notamment)
DO-178B
C'est mon second projet dans ce que les commerciaux aiment appeler "un contexte de DO-178B". En pratique, la DO-178B, est une norme aéronautique pour le développement d'applications critiques (le plus souvent embarquées sur avion). C'est une norme très sévère qui imposent de nombreuses règles pour la conception et le développement logiciel. Notamment :
- La gestion de configuration obligatoire
- La traçabilité "parfaite" entre les spécification et le code
- Les différents aspects de la validation et vérification (revue de code, indépendance entre le codeur et le testeur, couverture des tests...)
Au niveau dev...
C'est la première fois que je me retrouvais seul, en milieu pro, à prendre en charge le développement complet d'un soft. C'est un peu flippant au début, surtout quand on a été habitué à avoir des gars très bons techniquement à côté de soi, mais c'est aussi extrêmement enrichissant.
En particulier, le fait de devoir faire soi-même des choix au niveau de l'architecture du logiciel, des conventions techniques, du design, etc... c'est l'une des parties les plus intéressantes du développement (l'implémentation est sympa aussi, hein !).
Sans trop rentrer dans les détails techniques (qui seraient de toute façon une redite de pas mal de principes de base de conception logicielle), voici ce que j'en ai retenu :
- Les spécifications, quand elles sont écrites par quelqu'un d'autre qu'un codeur, sont forcément en décalage par rapport aux réels besoins, et par rapport à leur mise en oeuvre. Ce qui veut dire que celui qui code doit participer, et influencer au maximum cette phase de spécification. En gros : participer à cette expression des besoins plutôt que la subir ensuite.
- Avant même de réfléchir à la façon d'implémenter les fonctions demandées, identifier les problèmes à venir, d'un point de vue software (pas d'un point de vue système, ou métier), qui se posent et proposer une solution. Par exemple dans mon cas : grand nombre de variables en entrée et en sortie => création de façades ; uniquement des variables booléennes => créations de types structurés utilisés dans les interfaces de chaque fonction ; besoin temporaire de certains modes de fonctionnement => design pattern Strategy (non, il n'y a pas de POO dans SCADE, pour autant ça reste applicable) et séggrégation des fonctions par mode ; etc...
- Essayer de piquer les bonnes pratiques des langages modernes et/ou fonctionnels : pas de variables globales, éviter tant que possible les effets de bord, composer ses fonctions, etc...
- Le typage, c'est la vie.
- Communiquer au maximum : "Mon code est dans tel état là, maintenant.", "Telle partie sera disponible le tant.", "On va avoir des problèmes à tel niveau sur telle spec.", "Je suis en retard par rapport au planning à cause de tel problème.", etc... et de façon systématique et quotidienne. Cela permet d'éviter bien des mauvaises surprises.
- Séparer ce qui change de ce qui ne change pas (formulation honteusement pompé à Russ Olsen)
- Et les classiques : KISS, DRY, YAGNI, etc...
credits : photo de nacelle par Eric E Johnson
