Il arrive régulièrement d’accumuler de la dette technique dans un projet, cela peut par exemple arriver lorsqu’on essaye de coder rapidement pour respecter une dead line.
Quels techniques utilisez-vous pour en avoir le moins possible ? Comment la gérer-vous ? Comment la mesurez-vous ?
Allez je me lance : voilà trois principes que nous appliquons chez Cozy pour gérer la dette technique :
1 Une organisation en petits modules
Ca nous permet de bien découper tout ce que nous produisons et de privilégier certains modules à d’autres. Ainsi nous n’admettons que peu de dette technique sur les modules critiques (gestion des données par exemple). Par contre, nous sommes plus laxistes sur des modules qui sont encore en phase exploratoire ou qui ont peu d’impact sur l’ensemble de notre solution.
2 On développe le travail en pair
Ce principe est un peu nouveau chez nous (nouveau dans le sens que nous sommes plus rigoureux dessus que depuis récemment). Etant donné que tout notre code est sur Github, nous envoyons nos modifications à travers des Pull Requests que nous faisons valider par un de nos pairs. Nous faisons aussi du pair-programming via du partage d’écran pour partager la connaissance de manière plus efficace. Ca ne règle pas le problème de la dette technique, mais ça permet d’anticiper les problèmes à venir en limitant les dégats.
3 Nous adoptons une méthode réactive
Quand un module réclame trop d’aller er retours pour être débuggé, c’est que la dette technique est devenu trop importante. Nous posons le crayon et regardons ce que nous pouvons enlever ou mettre de côté tant dans l’existant que dans le backlog. Le fait d’enlever du code ou de revoir ses ambitions à la baisse permet de dégager du temps pour la qualité.
La deuxième étape consiste à coder les tests manquants et s’assurer que tout la chaine d’intégration continue est au propre. Une fois que c’est fait, si le programme est toujours instable, nous démarrons un refactoring de la partie concernée. Nous pouvons le faire sereinement grâce aux tests réalisés au préalable.
Il y a bien sûr plein d’autres petites choses mais l’essentiel est là !
Depuis mon stage chez Sogeti en 3 années quand j’étais aux études chez Supinfo, je suis un str8 up believer dans le TDD.
Si je n’avais qu’une seule recommandation à faire en arrivant quelque part où des gens codent un truc ce serait : “Les gars, les filles il faut mettre en place du TDD :-), Amen”.
Grâce à cela on réduit la pression au niveau responsabilité pour les développeurs (et oui parfois on peut avoir le doute sur la pertinence de ce que l’on à fait mais la on peut se rassurer avec un “le test passe donc c’est OK”). Cela je pense à une bonne influence au niveau organisationnel on se dit que le boss (chef technique et/ou fonctionnel) ne va juger que ce critère en priorité. Et quand on regarde ces objectifs on sait qu’on les a atteints ou non.
Quels techniques utilisez-vous pour en avoir le moins possible ?
Sur développement Spring Java par exemple (ce que j’ai toujours fait à la base en SSII) on va utilisé des outils de couverture de code.
Genre PMD (qui analyse la complexité du code), Cobertura avec derrière Jenkins pour afficher tout cela.
Avec Spring on programme d’office par interface entre les couches donc on peut tester chaque couche DAO, Services, Controller et même Vue.
Mais on contrôlait surtout les Services et les Dao(ou parfois il y avait des requêtes faites à la main(SQL).
Comment la gérer-vous ?
Et bien tout les soirs on fait tourner les tests d’intégrations et unitaires et le matin on vérifie que tout est verts (enfin l’essentiel). Certains choses sont désignés comme prioritaires. Et puis le reste on verra mais on laisse jamais le truc filer. C’est du faux temps gagné. Si on peut corriger rapidement on le fait.
Comment la mesurez-vous ?
Cobertura, Jenkins, Couverture du code quoi.
J’aime bien la règle du boy scout : http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule
Sinon, avec python (mais doit s’adapter aux autres langages), quand je code mal (et que je le sais) je rajoute un commentaire # FIXME pour que ça soit remonté par pylint, quand il y en a trop, c’est suffisamment ennuyant pour me décider à en corriger.