L'outil des gagnants

N’hésitez jamais à contredire l’architecte du projet. Déjà parce que ça fait un bien fou. Ensuite parce qu’il n’a pas toujours raison, malgré ce qu’il peut penser. L’architecte moyen imagine et définit le logiciel comme il doit être à terminaison, et oublie toutes les étapes par lesquelles celui-ci doit passer avant d’être achevé. Comme une bonne partie des informaticiens, il ne prend pas en compte la problématique de l’intégration. La loi de Murphy étant ce qu’elle est, l’architecte vous pondra à coup sûr une organisation du logiciel qui vous empêchera de l’intégrer. Voilà un premier ennemi clairement identifié et facilement repérable.

Petit exemple récent, bien navrant : un premier livrable, fournissant interface et implémentation homogènes, est fourni par une seule et même personne. Par contre, grâce à la magie de la gestion de configuration, et sur décision de l’architecte qui défini  le découpage modulaire du logiciel, ce code est saupoudré dans tout un tas d’autres composants qui l’hébergent. Donc, ils le relivrent, puisqu’il est chez eux ! Question à deux francs six sous : comment l’intégrateur va-t-il garantir l’intégrité de ce livrable ? Autre question : comment utiliser une nouvelle version de ce livrable sans attendre de relivraison des autres composants ? Parfois, les outils de gestion de configuration déployés sur votre projet pourront vous aider à résoudre ce problème, plus ou moins élégamment, mais toujours de façon un peu alambiquées Un alambic étant de loin le dernier outil dont vous ayez besoin pour sortir un logiciel, soyez ferme, et encore une fois, exigez :

Le logiciel doit être découpé et organisé en composants dissociés livrés indépendamment.

Ne nous méprenons pas, il reste malgré tout à assurer la cohérence des différents bouts de logiciels entre eux (vous n’espériez quand même pas être payé à ne rien faire non mais hé !), mais au moins, chaque bout du logiciel est identifié de façon unique et vu par tous de la même manière.

Vous pourriez rétorquer, comme l’architecte en question, que le premier livrable n’est qu’une chimère, un artifice de travail, et que ce qui compte, c’est ce que publient les autres composants qui chacun embarquent une partie du code. Ça pourrait effectivement être le cas si un dernier composant ne se basait pas uniquement et intégralement sur la soit-disant chimère diluée dans tout le logiciel. Pour ce dernier composant, l’artifice est une réalité concrète, un tout indivisible. Et puis, ce serait de toute façon oublier un peu vite le besoin de cohérence du premier livrable. Refusant d’admettre un seul instant qu’il aurait pu oublier une hypothèse de travail dans son raisonnement parfait par essence, l’architecte, sûr de son fait, vous assène un fantastique « Miroir magique ! De toute façon c’est plus logique d’avoir le découpage que notre bon vouloir aura imposé à terme ! » Certes, mais le projet est encore loin d’être terminé. Si, quand tout marchera parfaitement, l’architecte souhaite ranger les fichiers dans les répertoires qu’il souhaite, vous serez prêt à lui offrir un accès toutes zones. Mais la route est encore longue et sinueuse, la pente plutôt raide… et l’architecte déjà retourné dans son bureau après avoir soigneusement refermé sa porte.

À ce stade de la conversation, Lucifer vient généralement vous tapoter l’épaule en vous souhaitant bon courage d’un air condescendant mais satisfait. L’enfer est pavé de bonnes intentions. Et les architectes s’occupent de l’entretien des voies.