Fiabilisation de vieux code

De Breizh-Entropy
Révision datée du 21 août 2015 à 17:16 par Guest (discussion | contributions) (infect sans "e" au masculin)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)
Aller à la navigation Aller à la recherche
La version imprimable n’est plus prise en charge et peut comporter des erreurs de génération. Veuillez mettre à jour les signets de votre navigateur et utiliser à la place la fonction d’impression par défaut de celui-ci.

Que ce soit du code refourgué par un prédécesseur, écrit à la vite, ou ayant accumulé un retard technologique sur plusieurs années... il est fréquent d'avoir à retravailler sur du vieux code. Il est tentant de vouloir tout réécrire, en repartant sur de bonnes bases. Mais:

  • La plupart du temps le projet n'aboutit pas,
  • Au bout de quelques années le nouveau projet est devenu tout aussi pourri.

Un vieux code de jeu à reprendre

Cas d'école: prenons le jeu Dink Smallwood, un chouette jeu sorti vers la fin des années '90, et dont le code a été libéré.

Le code est infect: une poignée de fichiers monolithiques, des fonctions de 1000+ lines, des noms de variables à coucher dehors... Plus grave : plus de 400 Dink Modules (D-Mods), de nouvelles aventures faites par des fans, sont disponibles, et beaucoup s'appuient sur des bugs du moteur...

Comment faire un portage GNU/Linux sans tout casser ? Avec des modifications locales sur les I/O (graphiques/sons/clavier/joystick), une bonne connaissance du moteur, un peu de culot, plusieurs cierges à l'église, et beaucoup de tests manuels, c'est possible : GNU FreeDink.

Reprendre le contrôle sur du code pourri

À présent : comment faire évoluer le code, ou pire encore, accepter des contributions extérieures donc non-fiables, sans risquer d'introduire de nouveaux bugs, et casser les D-Mods sans s'en rendre compte ? La peur de casser finit par tout paralyser.

Working Effectively with Legacy Code, de Michael Feathers, propose une approche TDD. Il définit: legacy code is simply code without tests. L'approche proposée est :

  • Avant tout changement, introduire un maximum de tests unitaires dans la base de code,
  • Pour introduire des tests unitaires, changer le code pour le rendre testable,
  • Et pour sortir de ce cycle, amorcer avec des changements peu risqués :
    • Casser les dépendances internes pour y introduire des tests - l'essentiel du livre expose différentes techniques
    • Utiliser des outils de refactoring automatique

Pour C/C++, en libre, Eclipse CDT fournit quelques fonctions de refactoring, Rename et Extract Method.

Qu'est-ce que ça fout sur ce wiki ?

C'est ce que je fais en ce moment au hackerspace : se mettre au défi d'ajouter une armature de test autour de ce putain de code, et avoir confiance dans les prochaines modifs.