Logiciel et R&D : les Bonnes Pratiques

Grâce au développement des outils de calculs, le développement logiciel fait aujourd’hui partie de la vie quotidienne des ingénieurs R&D. Le code peut ainsi servir d’outil de coopération ou d’instrument de confusion; tout dépend de la qualité des bonnes pratiques exigées au sein de l’équipe.

Pierre BERNARDI, PhD, Consultant & Formateur en R&D, algorithmes et calcul… nous expose quelques fondamentaux trop fréquemment ignorés. CQFD Cadres 78 le remercie pour son autorisation à publier l’ensemble de son article.


 

Logiciel et R&D :
Un esprit sain dans un « code » sain

Par Pierre Bernardi, PhD

Le code est aujourd’hui partie intégrante de l’innovation. Cependant, les mauvaises pratiques de codage sont encore nombreuses dans les divisions de recherche et développement (R&D) car la programmation n'est pas le cœur de métier des ingénieurs. Pourtant, perdre le contrôle d’un modèle ou d’un algorithme peut nuire profondément à une entreprise. C’est particulièrement vrai en R&D où le logiciel englobe à la fois le produit et la technologie.

Le travail des équipes de RetD nécessite de multiples compétences. Les innovateurs travaillent dur avant de pouvoir maîtriser la myriade de connaissances technologiques et d’instincts mathématiques qui leur permettent de résoudre des problèmes. Et vous voudriez en plus qu’ils codent proprement ?

Pourtant, les produits créés deviennent de plus en plus gros et de plus en plus complexes. Les projets impliquent des professionnels de cultures et de compétences différentes. Au centre de cela, le code prend de plus en plus d’importance et il peut devenir un outil de coopération ou un instrument de confusion; tout dépend de la qualité des pratiques de codage exigées.

Le Mythe de Babel

L’histoire de la Tour de Babel présente certaines similitudes avec de nombreux projets de code R&D infructueux.

Au commencement, les humains parlaient tous le langage universel. Un jour, Nemrod les persuada de construire une tour qui touche le ciel. Cela rendit l’Éternel très mécontent. Il décida de programmer l’échec du projet en condamnant les hommes à parler des langues différentes. Les hommes devinrent incapables de maintenir la construction. Ils l’abandonnèrent. Finalement, ils se dispersèrent.

Pas de projet commun sans langage commun

Les algorithmes de votre équipe R&D sont profondément complexes. Que se passe-t-il lorsque chaque programmeur utilise ses propres codes à l’intérieur du code? Qu’arrive-t-il au projet lorsque la forme est laissée pour compte dès le départ?

• Faites que vos équipes utilisent une langue et des références communes pour éviter que votre projet ne se termine comme la Tour de Babel,

• Conseillez à vos ingénieurs R&D d’écrire du code expressif, c’est-à-dire un code qui dit ce qu’il fait,

• Demandez à chacun de formater sa propre production afin que le contenu soit clair pour le groupe.

 

Pas d’avenir sans passé

J’ai travaillé il y a quelques années pour une entreprise du secteur de la défense. Cette compagnie avait de gros problèmes avec ses anciens codes. Rien n’avait été fait pour assurer le transfert des connaissances lorsque les anciens ingénieurs avaient été mutés ou avaient pris leur retraite.

Un jeune ingénieur vint me voir un jour car il avait remarqué des erreurs lors de la compilation d’un de ces anciens codes. Jusque-là, les sources avaient été transmises négligemment par des sauvegardes locales successives. Finalement, le code s’était perdu au cours du processus. Cette perte mettait le projet de ce jeune ingénieur dans une situation d’urgence. Cela l’incitait à développer « Quick and Dirty », créant ainsi les conditions pour un futur désastre.

Ne laissez pas votre expertise se dégrader: tracez rigoureusement l’historique de votre code et (donc) de votre technologie

En R&D, votre technologie est inévitablement incluse dans votre code.
• Assurez-vous de sécuriser et de stocker rigoureusement votre expertise en utilisant un système
de gestion de configuration.

Si vous perdez votre code source, vous perdrez des traces de vos inventions.

 

 

Le coût astronomique de ne pas exécuter les tests

Souvenons-nous d’un exemple frappant de l’importance des tests de code en R&D.

En 1996, le premier vol d’Ariane V s’est conclu par l’explosion de la fusée environ 40 secondes après son allumage. L’explosion était due à un dépassement d’entiers dans le logiciel de navigation de la fusée. Afin de réduire les coûts, les simulations de test du système de navigation, qui auraient dû avoir lieu avant le vol, avaient été annulées. C’est la raison pour laquelle ce bug est advenu et c’est pourquoi la catastrophe s’est produite.

 

Ce qui est arrivé à Ariane V, est ce qui arrive tôt ou tard à tout code non rigoureusement testé

 

Beaucoup de gens pensent qu’écrire des tests consiste à écrire plus de code. La réalité est l’exacte opposée.

Vos ingénieurs R&D écriront toujours une « sorte de petit test » afin de vérifier que la fonction qu’ils viennent de modifier se comporte comme prévu. Mais ils se débarrasseront souvent de ce test immédiatement après, et passeront à la suite… en oubliant de s’assurer que leur nouvelle fonction n’impacte pas le reste du projet.

Au lieu de cela et a minima, ce test devrait être incorporé dans une base de test. Tous les tests devraient être exécutés à chaque modification du code. Cela permet de détecter immédiatement un comportement imprévu du code, d’identifier facilement l’origine d’un bug, de le corriger rapidement et donc de gagner beaucoup de temps. Cela évite également d’écrire et d’effacer encore et encore le même test comme on le voit parfois. Finalement, cela évite d’oublier de lancer un test important – comme ce fut le cas avec Ariane V.

• Assurez-vous que votre équipe R&D est consciente de l’importance des tests,
• Demandez à vos ingénieurs d’incorporer une fois pour toutes leurs tests dans une base de tests,
• Évitez que votre projet explose en plein vol en exigeant que tous les tests soient exécutés à chaque changement important du code ou du matériel,
• Envisagez sérieusement d’adopter une méthodologie de type « Test Driven Development ».

Sans tests, les bugs peuvent passer inaperçus et provoquer des dommages sévères. C’est pourquoi les tests ne doivent jamais être négligés.

Conclusion

L’adoption de bonnes pratiques de développement rencontre encore une résistance farouche au sein de nombreuses divisions de R&D. Ces bonnes pratiques que je viens d’illustrer, aujourd’hui plus largement répandues dans le secteur de l’IT, permettent pourtant de réduire drastiquement les coûts liés au code en accélérant les temps de développement, en augmentant la fiabilité des logiciels produits et en pérennisant les technologies.

Pierre Bernardi
Contactez-moi pour plus de détails !

 

Lien court : https://wp.me/p9haeE-s5

Fermer le menu