Vous venez d’hériter d’une base de code C++ legacy : que faire maintenant ?

Que faire quand on hérite d’une base de code C++ existante ?

• En arrivant dans un nouveau poste, en changeant d’équipe ou après le départ d’un collègue expérimenté, on peut se retrouver responsable d’une grande base de code C++ à la structure complexe et atypique.
• Il faut corriger des bugs et ajouter de nouvelles fonctionnalités, mais on ne peut ni ignorer ni jeter cette base de code. Elle est importante pour ceux qui paient les salaires, donc elle est importante pour vous aussi.

Première étape : faire tourner le code en local

• Faire fonctionner le code en local en apportant le minimum de modifications possibles au code et au système de build. Pas encore de gros refactoring.

Supprimer ce qui est inutile

• Retirer tout ce qui n’est pas absolument nécessaire pour fournir les fonctionnalités que l’entreprise ou le projet open source annonce et vend.

Faire entrer le projet dans le XXIe siècle

• Ajouter la CI (intégration continue), des linters, du fuzzing, du formatage automatique, etc.

Amélioration progressive du code

• Apporter de petits changements incrémentaux au code. Répéter l’opération jusqu’à amener le projet à un niveau acceptable en matière de sécurité, d’expérience développeur, de justesse et de performance.

Envisager une réécriture partielle dans un langage à sûreté mémoire

• Si possible, envisager de réécrire une partie du code dans un langage à sûreté mémoire.

Préciser les plateformes prises en charge

• Indiquer dans le README les paires <architecture>-<système d’exploitation> officiellement prises en charge. Par exemple x86_64-linux ou aarch64-darwin.

Faire fonctionner la build sur vos machines

• Veiller à pouvoir compiler de manière fiable et cohérente sur toutes les plateformes prises en charge.

Faire passer les tests sur vos machines

• S’il n’y a pas de tests, en écrire avant de modifier le code, les faire passer, puis revenir au changement prévu.

Décrire dans le README comment builder et tester l’application

• Simplifier les commandes de build et de test pour que même des non-spécialistes puissent les suivre facilement.

Chercher les fruits les plus faciles à cueillir pour accélérer la build et les tests

• Rechercher des moyens simples d’accélérer la build et les tests sans modifier le système de build.

Supprimer le code inutile

• Utiliser les avertissements du compilateur et les linters pour repérer et supprimer le code inutilisé.

Linters

• Sans se focaliser excessivement sur les règles des linters, en ajouter quelques-unes de base et les intégrer au cycle de développement.

Formatage du code

• À un moment opportun, appliquer en une fois un style de code uniforme à toute la base de code, puis versionner la configuration.

Sanitizers

• Utiliser des sanitizers pour détecter et corriger de vrais bugs ainsi que des fuites mémoire.

Ajouter un pipeline CI

• Automatiser tous les bons réglages mis en place (linters, formatage du code, tests, etc.) et produire des binaires pour toutes les modifications dans un environnement de production.

Amélioration progressive du code

• Se concentrer sur des objectifs concrets comme la sécurité, la justesse et la performance, plutôt que sur des critères subjectifs comme le « code propre ».

Réécriture dans un langage à sûreté mémoire ?

• C’est un chantier encore en cours, avec beaucoup de réserves. Ne le faire que lorsqu’il existe une raison claire.

Conclusion

• L’article propose un plan concret, étape par étape, pour se sortir d’une base de code C++ legacy complexe.

Annexe : gestion des dépendances

• En C++, il n’existe pas vraiment de gestion des dépendances, et on utilise le plus souvent les gestionnaires de paquets système. Mais c’est, selon l’auteur, une mauvaise idée.
• L’auteur préfère utiliser des sous-modules git et une compilation depuis les sources pour gérer les dépendances.

Avis de GN⁺

• Cet article fournit un guide étape par étape utile aux ingénieurs logiciels juniors qui héritent d’une base de code C++.
• Travailler sur du code legacy est un défi courant pour de nombreux développeurs, et cet article apporte des conseils pratiques pour ce type de situation.
• Le fait de souligner l’importance des tests dans le processus d’amélioration de la base de code reflète de bonnes pratiques de développement logiciel.
• L’avis de l’auteur sur la gestion des dépendances peut prêter à débat, et dans des projets réels, des gestionnaires de paquets modernes comme Conan ou vcpkg sont souvent utilisés avec succès.
• Lorsqu’on adopte des technologies, il faut tenir compte des spécificités du projet et du niveau technique de l’équipe, et cet article peut constituer un bon point de départ pour prendre ce type de décision.

[GN⁺]

Avis sur Hacker News

• Certains commentaires sur Hacker News donnent des conseils sur la reprise d’un projet C++ :

  • Builds reproductibles : il est recommandé d’encapsuler l’environnement de build avec des outils comme Docker afin de rendre les outils et dépendances explicites et reproductibles.
  • Build propre avec l’option -Wall : corriger les avertissements pour résoudre les problèmes du code et, plus rarement, ignorer un avertissement après l’avoir compris.
  • Il est suggéré d’effectuer des tests initiaux avec des outils comme Valgrind afin d’examiner les erreurs de lecture/écriture.
  • Il est recommandé de limiter au début le refactoring à une portée locale et d’éviter les grandes refontes avant d’avoir compris l’architecture globale.

• D’autres commentaires soutiennent qu’il est important d’introduire d’abord la CI, le linting, l’auto-formatting, etc. :

  • Avant de supprimer les parties inutiles du code, il faut comprendre comment le programme fonctionne, et les outils d’analyse statique peuvent apporter des indications sur les zones nécessitant du travail.

• Un utilisateur suggère de changer d’équipe ou d’entreprise.

• Certains commentaires mentionnent aussi l’importance des outils et techniques de compréhension du code :

  • Il est important d’utiliser des outils pour indexer la codebase, de créer des diagrammes de séquence UML et de prendre des notes comme si l’on devait l’enseigner à quelqu’un d’autre.

• Un commentaire donne des conseils pour moderniser le projet en ajoutant CI, linters, fuzzing, auto-formatting, etc. :

  • La CI permet de s’assurer que le build fonctionne aussi ailleurs, et les avertissements du compilateur ainsi que les analyseurs statiques aident à identifier les problèmes du code.
  • Mettre en place des tests unitaires sur les parties importantes du code permet de vérifier qu’il effectue bien les bonnes opérations.
  • Le formatage automatique est une priorité moindre, et il est recommandé de suivre le style du mainteneur d’origine.

• Un autre commentaire critique le conseil consistant à réécrire certaines parties dans un langage memory-safe :

  • Il peut être difficile d’obtenir les ressources nécessaires pour ce travail supplémentaire, cela exige des connaissances dans un langage additionnel en plus du C++, et les tests peuvent devenir plus complexes.

• Un commentaire affirme aussi que l’usage de git submodules et de la compilation depuis les sources est supérieur aux gestionnaires de paquets :

  • Il souligne qu’il est étrange de formuler ce type de critique avant même d’avoir essayé des outils comme vcpkg.

Ces commentaires présentent différentes approches et recommandations lorsqu’on hérite d’un projet C++, et reflètent des points de vue variés sur la gestion de projet, la compréhension du code, le refactoring et les stratégies de modernisation.