Cet article sur la dette technique présente de bons points, notamment:

Travailler sur les "questions techniques" fonctionne mieux quand il est motivé par des histoires. La base de code a probablement besoin de travail partout, mais le paiement ne sera reçu que là où le code va être travaillé pour des raisons liées à l'utilisateur. Si aucune histoire ne doit traverser une zone cruelle, y travailler est en grande partie gaspillé.

Par conséquent, je préfère l'approche consistant à prendre des histoires comme d'habitude (mais probablement moins) et à suivre la «règle du scoutisme» consistant à quitter le camping mieux que vous ne l'avez trouvé. En d'autres termes, où que les histoires nous mènent, écrivons plus de tests, refactorisons plus agressivement.

Cette approche présente au moins ces avantages:

• maintient le flux d'histoires "le plus sensé";
• fournit l'aide de tous les talents de l'équipe;
• permet à toute l'équipe d'apprendre à garder le code propre;
• concentre l'amélioration exactement là où elle est nécessaire;
• ne gaspille pas les améliorations qui "peuvent" être nécessaires;

J'ai vu que la qualité du code a un très grand effet sur la productivité à long terme, donc je suis convaincu que la dette technique devrait être prise en charge. Je pense que le post ci-dessus est logique, mais je ne suis pas sûr des deux derniers points. Je suis intéressé à découvrir des expériences réelles des avantages du nettoyage de la dette technique, même si cela n'était pas lié aux user stories.

Quels avantages positifs avez-vous constatés en nettoyant votre base de code et en vous débarrassant de vos dettes techniques? Quelles méthodes avez-vous utilisées pour faire le travail?

Je peux vous donner un exemple de mon expérience.

Il y a environ 10 ou 12 ans, j'ai hérité d'une application d'une équipe de développeurs qui a fini par quitter l'entreprise (trop longtemps pour entrer ici ...). Le système était un grand système de génération de rapports middleware maison. Il a fonctionné tous les soirs de la semaine et a généré environ 2 douzaines de rapports Excel pour les cadres supérieurs d'une entreprise Fortune 500. Quand je l'ai hérité, il a fallu environ 5-6 heures pour fonctionner et au cours d'une semaine donnée, j'échouais au moins 2 nuits.

Je n'étais pas un campeur heureux de recevoir ce bordel.

Au départ, mon plan était simplement d'arrêter le saignement et de corriger la principale cause des échecs. Après être devenu plus à l'aise avec la base de code, j'ai commencé à chercher des endroits où je pouvais refactoriser et ajouter de la stabilité et des performances. En l'espace de 2 ans environ, j'ai apporté de très nombreux changements au système. Nous avons supprimé ce système il y a quelques années et à ce stade, le processus a duré 45 minutes et n'a généré aucun problème depuis des années.

Beaucoup de travail a été consacré au remboursement de la dette technique, mais cela en valait la peine. C'était bien de ne pas recevoir d'appels téléphoniques au milieu de la nuit que le système a échoué. C'était agréable d'entrer dans le bureau le matin et de ne voir que de bonnes nouvelles dans les journaux.

(Mis à part ... Après quelques années, je suis tombé sur l'un des principaux développeurs de ce système. Il m'a demandé comment il fonctionnait et je lui ai dit à quel point le système était mauvais. Il s'est en fait excusé et m'a dit qu'il savait que ce serait une poignée de soutien après son départ et j'aurais aimé avoir fait un meilleur travail à ce sujet).

D'après mon expérience, les avantages du nettoyage de code sont plus visibles lorsque je dois conserver du code là où le nettoyage n'a pas été effectué. Là où le nettoyage a été fait, mes modifications consistent à lire le code, à repérer un ou deux endroits qui doivent être modifiés et à partir de là. Si le nettoyage n'a pas été fait, ajoutez une première étape de lecture du code plusieurs fois et essayez de comprendre ce que l'auteur (parfois moi) pensait quand il l'a écrit.

l'élimination de la dette technique donne moins de soutien technique et une meilleure base pour les améliorations

toujours

J'ai vécu une expérience lorsque je dirigeais une équipe de performance du site chez mon ancien employeur. Chaque nuit, pendant une période d'une heure à deux heures, le site Web que mon équipe surveillait plongeait en dessous des seuils de performance acceptables en raison d'un bot grattant rapidement les informations du site. Les mesures que l'équipe a prises pour résoudre ce problème ont consisté à se connecter à un système d'administration manuel et à bloquer les adresses IP à l'origine des problèmes. Inutile de dire que cela a coûté à un membre de l'équipe des heures de sommeil presque chaque nuit. J'ai remarqué ce qui se passait et j'ai moi-même pris le BlackBerry sur appel pendant plusieurs jours pour voir à quel point c'était mauvais et donner à mon équipe un peu de repos.

Après quelques jours, je suis simplement allé voir le propriétaire de l'équipe et lui faire savoir que si nous n'implémentions pas un système de blocage automatisé tel que les bots auraient beaucoup plus de mal à affecter les performances du site, nous perdrions probablement certains sinon tous les membres de l'équipe en raison de la fatigue et de l'épuisement professionnel. Ils ont accepté et nous avons mis en place un système qui nous permettait de dormir la nuit. Le propriétaire d'entreprise a compris que le coût de quelques jours ou d'une semaine de développement était minime par rapport au coût d'embauche / formation de nouveaux ingénieurs.

Concernant les deux derniers points: je comprends d'où ça vient, comme expliqué dans son billet d'origine :

Ou, est-il possible de réaffecter certains développeurs pour résoudre ces problèmes techniques, tandis que le reste de l'équipe continue sur les trucs orientés utilisateur? Cela peut affecter la vitesse de l'équipe, mais alors quoi?

"Alors quoi" est égal: le propriétaire du produit et les autres gens du monde des affaires deviennent mécontents. Et quand maman est malheureuse, tout le monde est malheureux.

Pourtant, la frontière entre ce qui doit être fait et ce qui peut être fait est assez vague. L'utilisateur est très large et comprend les performances et la survenue d'erreurs. Mais dans certains cas, le problème sous-jacent des performances médiocres et de la fréquence élevée des erreurs est plus profond dans le code. Pour le dire avec ses mots: une histoire peut ne pas traverser une zone cruelle, mais cette zone cruelle peut cacher des choses désagréables qui attaquent l'histoire sur le chemin nettoyé à côté d'elle.

Les choses qui n'influencent pas la performance globale sont moins intéressantes à nettoyer, mais il faut évaluer très attentivement l'influence de ces points. Le plus souvent, ils ont une influence indirecte qui peut être assez importante.

Le principal avantage qu'une organisation recevra du fait du remboursement de sa dette technique est d'éviter les intérêts composés. Il y a un exemple dans l'entrée de blog ci-dessous qui montre comment le principal dû sur une dette technique est passé de 160 000 $ à 430 000 $ en seulement cinq ans. Il faudrait un programmeur à temps plein uniquement dédié au service de ce montant de dette. Cela aidera à mettre les choses en perspective pour les décideurs!

Sur blog.acrowire.com .