8 actions applicables tout de suite pour gérer la dette technique
Temps de lecture estimé : 7min
Dans les deux derniers posts je vous ai partagé ce que j’ai appris pendant la master class de Michael Feathers à laquelle j’ai assistée, et dont le sujet était : “Reducing Technical Debt”.
On a parlé de la définition de la dette technique, du characterization testing, du scratch refactoring, dans le premier post
J’ai ensuite abordé dans le dernier post plus précisément ce que l’on appelle le “refactoring” et comment s’attaquer aux parties les plus critiques du code, pour maximiser le retour sur investissement.
Aujourd’hui je vais vous partager 9 petites actions à faire pour améliorer la gestion de la dette technique au sein d’une équipe, et c’est tout droit tiré de l’expérience professionnelle de Michael et ça ne figure pas dans son livre !
Design Decision Cards
Lorsque l’on parle de gestion de la dette technique, et donc de la complexité d’un projet, cela revient souvent à parler de gestion du risque.
Chaque décision que l’on prend, que ce soit pour un potentiel “quick win” ou au contraire un investissement à plus long terme pour gagner en qualité de code et en temps de développement dans la durée, est toujours un pari.
Les Design Decision Card sont donc un outil simple permettant de garder une trace de tous les compromis que l’on fait par rapport au design, et que l’on considère avoir à réévaluer plus tard.
Il s’agit ensuite de revenir régulièrement sur ces notes pour estimer à nouveau le temps que cela prendrait de faire le changement escompté en fonction de l’évolution du projet, et ainsi voir si la balance penche maintenant nettement en faveur d’un refactoring.
Suggestive Refactoring
Cette action vient un peu à l’encontre de l’agilité.
Il s’agit de créer des petites “stories” liées au refactoring et les ajouter au backlog.
Les stories techniques sont un anti-pattern dans l’agilité, car chaque user story doit être considérée du point de vue de l’utilisateur, et du gain potentiel qu’il en tirera.
L’idée ici est donc plutôt de mettre en évidence les éléments de refactoring que l’on a pu identifier, dans l’espoir que ces stories servent de vecteur de communication pour l’équipe.
Split Prep-Refactorings
Si vous lisez régulièrement mes posts, sur LinkedIn ou ici, vous avez déjà dû tomber sur cette citation de Kent Beck :
“For each desired change, make the change easy (warning: this may be hard), then make the easy change” - Kent Beck
Lorsque l’on doit ajouter une fonctionnalité ou en modifier une, si le code respecte le Open-Closed Principle alors le changement est simple à faire (“make the easy change” dans la citation ci-dessus)
En pratique, surtout lorsque l’on s’attaque à la dette technique, c’est rarement le cas.
Il faut donc d’abord faire en sorte de modifier le code pour qu’il respecte le Open-Closed Principle (“make the change easy (warning: this may be hard”).
L’idée derrière le Split Prep-Refactoring est d’incomber ces deux taches à deux personnes différentes. Cela génère ainsi de la discussion par rapport à la compréhension du code qu’en ont les deux collègues et permet donc d’être plus efficace dans le refactoring.
Privileged Abstractions
Certaines abstractions sont au cœur de la complexité d’un projet.
L’idée est donc ici de les sélectionner, et de les documenter pour générer de la discussion entre les membres de l’équipe.
Pour ce faire, on peut utiliser la méthode “Telling the story of the system”.
Elle stipule tout simplement : “If you can't explain your architecture with 4 objects, you don't have an architecture”.
Cela permet par exemple de mettre en évidence des niveaux d’indirection en trop, créant de la complexité accidentelle.
Limited WIP Refactoring
Les connaisseurs de Kanban se retrouveront parfaitement dans cette action très simple à mettre en place : ne jamais avoir plus d’un ou deux gros chantiers de refactoring en même temps.
En pratique, cela signifie qu’il y a une limite WIP (Work In Progress) assignée aux grosses tâches de refactoring, et que si un troisième chantier de refactoring doit commencer, alors on privilégiera plutôt de terminer les 2 premiers déjà en cours avant.
Feature Trend Card
Alors celle-là est vraiment farfelue, et pourtant extrêmement intéressante !
Imaginez une fonctionnalité complexe qui a du sens pour votre projet, mais que vous savez que vous n’allez jamais implémenter.
Régulièrement, mettez-la dans le backlog, et estimez-la comme si vous deviez la développer vraiment.
L’idée est de comprendre les différentes zones de code que cela pourrait toucher et donc l’impact sur la dette technique.
À première vue cela semble totalement aller à l’encontre de tous les principes du style YAGNI et autre ! L’intérêt est en fait de forcer la réflexion sur l’architecture en prenant du recul. À être trop souvent la “tête dans le guidon” on ne s’aperçoit même plus que notre architecture nous dépasse, et qu’elle devient une sorte de plat de spaghettis infâme, où la complexité explose et la dette technique avec…
Silent Alarms
Celui-là je l’aime beaucoup aussi.
L’idée est de laisser les gens faire des erreurs, pour justement en apprendre plus sur le type d’erreur qu’ils sont susceptibles de commettre, et ainsi comprendre où résident les zones d’ombres les plus insidieuses du code.
Imaginons par exemple que vous souhaitiez imposer dans le code un sens de dépendance, et vous assurer qu’aucun développeur ne cherche à importer tel ou tel module depuis un autre. Des outils comme ArchUnit permettent de le scripter et donc de l’automatiser.
Qui dit automatiser dit que le “build” ne passera pas si les règles sont enfreintes.
Bonne chose n’est-ce pas ?
Eh bien pas forcément.
En fonction des types de règles, cela pourrait tout simplement amener le développeur frustré à contourner la règle pour que le build passe.
S’il fait ça, c’est la double peine :
l’information comme quoi il y a une erreur de dépendances est perdue
l’information concernant une incompréhension de sa part sur le projet est passée sous silence
Si à la place, on laisse le build s’exécuter, mais qu’une alerte est envoyée dans un canal Slack par exemple, alors cela devient une occasion d’apprendre de cette erreur, pour mieux communiquer autour des bonnes pratiques dans le projet par exemple :)
Transparent Design Quality
Un des objectifs initiaux de l’agilité était de résoudre le problème des projets qui échouaient à cause d’un manque de communication entre les développeurs et le business.
Si le discours entre le business et les développeurs est unilatéral, du style : “voilà les specs, maintenant, démerdez-vous à nous coder tout ça !”, les développeurs se contentent de donner des estimations, et il n’y a pas de place pour la qualité logicielle.
Et si la qualité du code transparaissait pour que le business le prenne en compte ?
C’est tout l’intérêt de cette méthode : faire apparaître la qualité logicielle pour qu’elle entre en jeu dans les considérations business.
Pour ce faire, c’est encore une fois très simple. L’idée est d’avoir une vue simplifiée du système, très gros grains, un schéma avec des blocs et des lignes que vous pourriez montrer à votre grand-mère.
Chaque bloc, qui correspond donc à un domaine métier parlant pour le business, se voit attribuer une couleur qui définit l’état du système. Vert = le système est OK, simple à faire évoluer et à maintenir. Rouge = attention, le système est plus difficile à maintenir. Et toutes les nuances entre le vert et rouge pour déterminer plusieurs niveaux de qualité.
Quand une nouvelle fonctionnalité arrive, on peut ainsi montrer explicitement les différents blocs impactés, et en fonction de leur couleur faire comprendre que cela prendra plus ou moins de temps à développer, car la qualité doit être améliorée dans telle ou telle partie avant que la fonctionnalité puisse être livrée comme attendu.
La qualité devient donc “visible” au sens business, et le fait de prendre du temps pour réduire la dette technique d’un bloc en augmentant sa qualité est maintenant vu par le business comme un investissement et non plus comme un coût ;)
Attention toutefois à bien utiliser des valeurs abstraites, et non discrètes comme des chiffres par exemple. Si l’on remplaçait les couleurs par des chiffres, le business pourrait avoir tendance à se focaliser dessus sans intérêt réel derrière, mais juste par pure manœuvre managériale : “pour la semaine prochaine, on aimerait que le bloc B passe de 41.45 à 42” => aucun intérêt.
Pour en savoir plus à ce sujet je vous invite à aller lire l’article de Colin Breck : Quality Views
Voilà qui clôt le chapitre de la masterclass de Michael Feathers sur la réduction de la dette technique :)
J’espère que vous avez apprécié ces trois derniers articles, comme d’habitude n’hésitez pas à répondre à ce post si vous avez la moindre question !
Happy Coding :)