Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
École du tech lead: Conversation autour de la dette technique
----
TLDR de Cyrille Deruel @CyrilleDeruel
Les 3 phrases sur la dettes
- Pas dépuration de la dette sans refactoring et pas de refactoring sans tests automatisés
- Normalement tu n'as pas besoin d'aller chercher la dette, c'est la dette qui te trouve
- Ta dette tu la gères tous les jours
Les 3 rituels graduels pour gérer sa dette
- Code Review obligatoire
- Revue de code collectif
- Dojo de fin d'itération (pour les changements importants)
Les 3 bons réflexes :
- Règle du boy-scout : l'endroit doit être plus propre quand tu le quittes
- Journée du Jardinage : 1 fois par mois, l'équipe bloque sa journée sur des tâches de désendettement qui n'ont pas été traité sur le mois
- Maintenabilité Check : Est-ce qu'en 5 min je suis capable de comprendre le code et savoir ce qu'il fait ?
Hors catégories
- La dette technique ce n'est pas que dans le code, c'est aussi l'UDD et hors du code
- La notion de dette technique doit être partagée par l'équipe de développement et le client
----
CR au fil de l’eau
Quels indicateurs de dette technique ?
- On ne touche pas sinon ça va casse
- On ne touche pas, il n’y a que X qui connait
- Anomalie dans les chiffrages sur un composant
- Quand on arrive sur un nouveau projet et qu’on récupère du code endeté, sur un client qui a payé moins cher
- Pas de test
À quoi on reconnait du bon code ?
- Code maintenable sur lequel tu peux agir en confiance
- Code refactorable
- Vélocité haute
- Les mêmes user stories devraient couter de moins en moins cher, en cas de dette leur coût augmente
Dans le monde financier une dette c’est pour atteindre un certain objectif (acheter une maison), est-ce que dans le monde IT c’est le même cas ?
En faisant des choses plus rapidement qu’on le devrait on crée de la dette plus rapidement qu’en temps normal, mais il ne faut pas escamoter la dette ensuite mais la prendre en compte dès le début (exemple: on fait du quick & dirty pour le jalon x, on planifie le refactoring dans le jalin x + 2). Le reste du temps on créé quand même de la dette en continu qu’il faut traiter par de l’amélioration continue.
Éviter les paiement d’un bloc qui a un trop gros impact sur la livraison de nouvelles fonctionalités: si possible le faire sur plusieurs jalons même si ça a un surcout à cause des merge.
Gros chantiers: séparer l’équipe en deux pour qu’une partie soit dédiée à une grosse migration est mauvais pour la cohésion de l’équipe.
Comment mesurer la rentabilité d’un investissement pour rembourser de la dette technique ? Il faut une situation de confiance avec le client pour qu’il accepte ce chantier.
Au pire on arrive à s’adosser sur un soucis bloquant qui déclenchera le chantier (fonctionalité nécessaire impossible à mettre en place avec une version existante, produit en fin de vie).
Pratiques de planifier des moments dans les itérations pour se focaliser sur la dette.
Comment est ce qu’on peut la factualiser pour pouvoir prendre des décisions objectives ?
L’idéal c’est de la purger au quotidien, sinon une bonne pratique est de référencer quelque part les points de dettes, mais attention à trop d’empilements => possible de déclencher automatiquement du désendettement quand le nombre de ces éléments sont trop nombreux.
La dette technique ne se limite pas au code: UDD par exemple, et dans ce cas il est plus facile de l’ignorer et de le laisser s’accumuler, il faut être vigilant.
Est ce que la vision du code endetté est partagée dans l’équipe ? Les peers review permettent ce genre de choses, par exemple en fin de user story.
Est ce que toute dette est bonne à corriger / comment faire pour décider ?
Très important de ne pas introduire de régression dans ce genre de refactoring qui n’apporte pas de nouvelles fonctionalités.
Est ce qu’il y a besoin de passer du temps à identifier la dette ? En principe la dette te trouve: tu identifies la dette par les douleurs, si du code est endetté mais qu’il ne te gène pas car tu n’interviens pas dessus dans ce cas c’est pas grave.
@ssaunier

This comment has been minimized.

Copy link

ssaunier commented Nov 12, 2013

Est-ce que vous avez déjà un outil pour évaluer la dette technique lorsque vous récupérez un projet? Lorsque je suis confronté à une codebase, je fais toujours la même chose, je regarde combien il y a de modeles, de controlleurs, la tete de ces derniers, voir si il y a des tests, la couverture, si ils passent tous, quelles sont les versions des gems majeures (rails, devise, etc...) pour me donner une idée de l'état du code.

Si vous avez un truc qui automatise je prends, sinon je sens que je vais me faire un(e) gem.

@archiloque

This comment has been minimized.

Copy link
Owner Author

archiloque commented Dec 19, 2013

On en a discuté et on pense que si la qualité du code se mesure bien avec des outils automatisé (même si en ruby ils sont moins courants qu'en java par exemple) la dette technique elle est souvent plus structurelle et se prête moins bien à la mesure automatisée.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.