« Fiabilisation de vieux code » : différence entre les versions

De Breizh-Entropy
Aller à la navigation Aller à la recherche
(Qu'est-ce que je fous au HS)
 
(infect sans "e" au masculin)
 
(2 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 10 : Ligne 10 :
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...
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 moeteur, un peu de culot, plusieurs cierges à l'église, et beaucoup de tests manuels, c'est possible : [http://www.gnu.org/software/freedink/ GNU FreeDink].
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 : [http://www.gnu.org/software/freedink/ GNU FreeDink].


== Reprendre le contrôle sur du code pourri ==
== Reprendre le contrôle sur du code pourri ==

Dernière version du 21 août 2015 à 17:16

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.