L’entropie est une notion sympathique. Il y en a partout, puisque la nature a horreur du vide. C’est donc tout naturellement qu’on en trouve plein la boîte crânienne des architectes, qui manquent systématiquement une occasion de se taire. Petit cas concret.

Un logiciel a été commandé par le client, il va falloir le développer. Ce logiciel fera plein de choses magiques et intéressantes. La révolution est en marche, la singularité à portée de vue. Parmi toutes les activités de ce logiciel, il est en une particulièrement épineuse. Il va remplir des traces dans un format cryptique, par exemple les résultats de son auto-analyse. Oui, les logiciels fiables savent dire si tout se barre en sucette et qu’ils doivent être remplacés par la nouvelle génération. Sac-à-papier ! il va également falloir fournir un analyseur de traces alors ? Ça se complique méchamment.

Hé ! oui, ça se complique : ce n’est plus un logiciel qu’il faut fournir, mais deux. Et puis surtout, il va falloir trouver un moyen pour forcer le pinpin qui devra se servir de tout ça à utiliser l’analyseur de traces qui correspond au logiciel qui tourne. Imaginez, s’il cherche à lire les traces produites par la version B avec l’analyseur de la version A, ou le contraire … Il risque de détecter des erreurs qui n’en sont pas, nous pourrir en réunion, et on passera trop de temps à chercher des problèmes qui n’en sont pas. Non, vraiment, il faut garantir que l’analyse des traces soit consistante.

Aujourd’hui, c’est jour de chance. L’architecte a déjà pensé à tout. On va introduire des numéros de version dans les binaires, et modifier l’analyseur pour que la première chose qu’il fasse soit de comparer son numéro de version avec celle du logiciel qui a produit les traces, comme ça, ni une, ni deux, si c’est pas pareil, il refuse de travailler, et fini les soucis. À cette fascinante idée j’opposerai deux arguments :

1. Un bon numéro de version doit être unique. Il devrait donc être généré automagiquement, sinon il risque de mal vieillir. Et non, il ne faut pas juste un nouveau numéro à chaque livraison, mais bien à chaque production, sinon je ne sais pas trop comment les testeurs peuvent travailler. Ah ! tiens : subtilement, ce que l’on imaginait comme une activité pour le gestionnaire de configuration vient de vous échoir, là, pour vous, intégrateur ;
2. Est-ce que le client va vraiment se contenter d’un analyseur de traces muet ? Je suis d’accord, mieux vaut se taire que de dire n’importe quoi (non, même là, il n’a pas compris), mais pour autant on ne rend pas plus service. Pire, du point de vue du client, on ne respecte pas le contrat : on devait faire une analyse qu’on ne conduit pas de toute évidence avec notre outil muet.

Au final, j’ai proposé une solution alternative : et si on s’assurait plutôt de la rétrocompatibilité des traces ? C’est-à-dire que les traces de la version B n’auraient pas rien à voir avec les traces de la version A, mais seraient un sur-ensemble ? Et le tout stocké dans un format ultra-novateur, du genre (identifiant, valeur) ? Au pire, si l’identifiant est inconnu de l’analyseur, il afficherait la donnée binaire brute, histoire de mettre la puce à l’oreille.

Allez comprendre pourquoi, cette solution trop simple a déplu. Je m’en fiche, je n’assure pas le S.A.V., bonne chance à eux.

Les réjouissances continuent. De Jean-Pierre Liégois, jeune lecteur du Var (ou presque) :

Hier soir, plantage de l’appli au démarrage. Après investigation au debugger, un S/T explique que c’est la fonction d’initialisation de la RAM à 0 qui plante.
Du coup ca matin, tout le monde sur le pont pour vérifier la gestion de la RAM, la taille utilisée, regénérer l’exe pour être sûr qu’il n’ y a pas des décalages d’adresse ou truc du même genre … Impossible de résoudre le problème.
Dans l’après-midi, on retourne sur le banc pour refaire un coup de debugger, et la, surprise, le plantage n’est pas du tout sur la fonction indiquée la veille mais bien plus loin dans l’appli, sur une ligne qui, oh surprise encore, a été modifiée dans un correctif !!!
Conclusion : quand un S/T vous dit que le problème est là, surtout ne pas regarder là …

Là encore, rien que le pain quotidien du développement logiciel de logiciels embarqués. Le logiciel n’arrête pas de grossir, il y a forcément un moment où les constantes de dimensionnement appliquées depuis toujours ne conviennent plus : nécessité de faire grossir tel ou tel segment mémoire, de revoir les options du compilateur pour espérer gagner de la place, etc. Ce genre de choses est d’autant plus réjouissant que l’on sait que ça va arriver, tôt ou tard. Et pourtant, il n’y a jamais personne pour préparer la copie, car c’est autant de sous d’économisés tant que les limites ne sont pas atteintes. Par contre, une fois atteintes, la balance financière est rarement gagnante quand il s’agit de revenir à la normale. Mais passons.

À votre petit niveau d’intégrateur, que pouvez-vous faire dans le cas décrit plus haut ? Et bien avant tout, vous méfier ! Alors comme ça, d’un coup, la gestion de la mémoire est bancale parce qu’on a rajouté une condition dans le code ? Moi-même je ne compte plus les remarques du genre « ha non mais le problème est dans la libc » ou bien « c’est le compilateur qui doit être buggé ». Il faut avouer qu’il est difficile de lutter contre ce genre d’argument souvent invérifiable, d’autant plus si les outils en question sont connus et reconnus pour être particulièrement obsolètes et truffés de (non-)fonctionnalités amusantes. Sans compter les messages amusants que peuvent produire un débordement de pile … Tout de même, ce genre d’alerte doit effectivement vous inquiéter, mais ce n’est pas le message premier le plus inquiétant !

Il n’y a donc pas trente-six solutions : reprendre l’analyse du problème avec le porteur de mauvaise nouvelle. Avant de sortir la grosse artillerie des experts techniques qui, bien que roués à cet exercice, seront d’autant plus amers que le problème incriminé sera tout sauf avéré.

Je ne résiste pas à poursuivre l’analyse de tranches de vie que je reçois :

Hier matin, nouvelle génération : Ca plante toujours à la compilation. Conclusion : quand y a un mec qui dit dans son mail de mise- à-disposition des entrées « attention j’ai modifié le nom d’un fichier, faut mettre à jour les scripts » c’est pas pour faire chier, c’est bien parce qu’il faut mettre à jour les scripts.

C’est bien plus court que la fois précédente, et pourtant c’est toujours aussi riche en enseignements. Sur chaque projet, il ya un processus plus ou moins officiel de livraison : méls, bordereau de livraison, etc. Ils permettent deux choses :

1. À celui qui le rédige, de vérifier qu’il n’oublie rien avant de passer le relais ;
2. À celui qui le reçoit, de prendre connaissance d’informations complémentaires éventuelles en plus des informations habituelles qui permettent d’adresser le travail quotidien.

Du coup, négliger cet acte de livraison, par l’un ou l’autre des parties, est nécessairement source de soucis.

Deuxième point, plus directement destiné à l’intégrateur : les index de production, c’est la lie ! Quel est le but premier d’un index de production ? Lister les fichiers qui seront pris en compte dans l’exécutable final. À l’origine, l’intention est louable : ça donne l’illusion de maîtriser son périmètre de production. Je dis illusion parce que ça ne fait pas tout : identifier un nom de fichier ne permet pas d’en donner la version. Et puis surtout, avec le temps, un index de production, ça sert aussi à plein d’autres choses. Ça sert à filtrer le contenu du système de fichiers. Ça sert à ranger proprement ce qui ne l’est effectivement pas dans le système de fichier. Ça sert à cacher ce qui ne devrait pas être visible de tous. Ça sert d’excuse quand ce n’est pas à jour. Un vrai cache-misère. D’autant plus que par construction un index de production est obsolète et un frein à la productivité. Une surcouche inutile à l’encontre de la logique, qui fait bien souvent dire « mais il est là mon fichier, vas-y, compile, [propos ordurier exclusivement destiné au sélectionneur de l'Équipe de France, donc censuré]« 

Quel outil doit être le garant du contour de la production, c’est-à-dire la liste des fichiers et leurs versions ? Il y a un piège, il faut deux outils :

1. Le gestionnaire de version de code source, qui permet toujours de retrouver un certain état global du projet à partir d’un identifiant approprié pour peu qu’il ait été posé ;
2. La chaîne de production, basée sur des règles simples, comme par exemple : tout fichier dans SRC est compilé, et tout entête trouvé dans le répertoire INC est public.

Utilisez les outils pour ce qu’ils sont sensés faire, et tout de suite, ça ira mieux.