Dette technique: tout le monde l'a, et chaque développeur digne de son titre veut le rembourser, mais comment organisez-vous ce processus?

Nous mettons en œuvre la rotation des cultures

Dans mon article précédent, j'ai comparé le remboursement de la dette technique à l'importance de la rotation des cultures dans l'agriculture. Si vous continuez à traiter un champ (codebase) saison après saison afin d'obtenir une grande récolte (projets complets, ajout de fonctionnalités, etc.), et ne donnez pas à ce champ une saison pour récupérer (paiement de la dette technique), alors il commence progressivement à perdre sa qualité et sa productivité.



Cette métaphore reste appropriée pour le développement de logiciels; en outre, il contient des indications sur les stratégies possibles qui peuvent être utilisées pour rembourser la dette technique.



Il existe un éventail étonnamment large de façons de rembourser la dette. Et cela est très utile car cela nous donne de nombreuses options de planification.



Pour les besoins de cet article, nous supposerons que vous travaillez dans une méthodologie de développement agile, mais de nombreux principes, s'ils sont affinés de manière créative, s'appliquent à d'autres méthodologies.

Sprints dédiés pour rembourser la dette technique

En pleine analogie avec la rotation des cultures, nous pouvons arrêter de travailler sur des fonctionnalités tous les quatre sprint environ, en ne les allouant que pour rembourser la dette technique.



Avantages:

• Les développeurs partagent une volonté commune de se concentrer uniquement sur le remboursement de la dette technique
• Les développeurs peuvent se coordonner pour rembourser de plus gros morceaux de dette technique en travaillant en tandem
• Les entreprises sont motivées pour étudier les résultats de la dette technique qui démontrent l'importance du travail et le volume restant.

Moins:

• Des conflits de fusion commencent à survenir à mesure que les employés apportent de plus grands volumes de modifications architecturales.
• Avec ce chaos et cette instabilité, il peut être difficile de dire si quelque chose est cassé s'il n'y a pas de bonne couverture de test.
• Tout simplement parce que vous travaillez sur la dette technique, les incidents de support ne disparaissent jamais. Sans personnel pour aider à l'escalade des demandes de soutien, la dette technique est garantie d'être entravée par le soutien.

Capacité dédiée au remboursement de la dette technique

Dans ce modèle, l'équipe agile réserve un certain nombre de points ou un pourcentage de la capacité totale de sprint pour payer en permanence la dette technique. Par exemple, dans chaque sprint, une équipe peut prendre 5 pièces de stockage de divers travaux de remboursement de dettes.



Avantages:

• Cela garantit que le remboursement de la dette technique fait partie de la culture permanente de l'organisation.
• Les travaux en cours sur la dette technique peuvent éviter d’avoir besoin de travaux supplémentaires à l’avenir.

Moins:

• Si des modifications doivent être apportées au sprint, travailler sur la dette technique sera le candidat le plus susceptible d'être retiré du sprint.
• En limitant votre travail sur la dette technique à de petits montants, vous rendez plus difficile l'élimination de la dette technique parfois importante.

Dédier les employés au remboursement de la dette technique

C'est un hybride des deux dernières options. Chaque sprint sélectionne un développeur pour travailler sur la dette technique tandis que tous les autres continuent leur travail normal.



Avantages:

• , , .
• , ,

:

• ,
• , , capacity

Dans ce modèle, lorsque les développeurs planifient leur travail, ils ajoutent au plan le nettoyage du code voisin et le paiement de la dette technique détectable qui se trouve déjà dans la zone de travail. Ceci est conforme au principe des Boy Scouts : laissez toujours le parking (base de code) plus propre qu'il ne l'était avant vous.



En d'autres termes, cela implique que lorsque vous touchez le code, cela devrait s'améliorer. Dans le code qui est le plus souvent touché, vous devez payer le pourcentage le plus élevé de la dette technique, il est donc logique de rembourser la dette dans les zones du code sur lesquelles vous travaillez.



Un concept similaire se trouve dans le livre de Malcolm Gladwell, The Tipping Point.pour un exemple du métro de New York. La City Transportation Authority a constaté qu'en découplant les wagons de métro, en les nettoyant des graffitis et en veillant à ce qu'il n'y ait pas de graffitis à tout moment, vous pouvez économiser sur l' effet des vitres brisées , dans lesquelles les gens croient que l'état des voitures ne dérange pas n'importe qui et le taux de criminalité peut augmenter. En réduisant le nombre de lapins et de graffitis, l'agence pourrait également réduire le nombre de crimes violents dans le métro.



Si nous transférons le même principe à notre base de code, nous devons faire en sorte que lorsque vous touchez des zones du code, elles soient nettoyées et la dette technique payée.



Vous avez probablement deviné d'après ce que vous avez lu ci-dessus que je suis fan de cette approche, mais considérons toujours ses avantages et ses inconvénients.



Avantages:

• La dette technologique est payante dans des domaines que les développeurs touchent naturellement plus souvent
• Vous n'avez plus besoin «d'allouer de l'espace» pour payer la dette technique, cela fait simplement partie du flux de travail
• Les conflits de fusion sont minimisés car les modifications ne sont apportées que dans des zones isolées.

Moins:

• Il n'y a pas d'opportunité spéciale d'apporter des modifications importantes qui affectent l'ensemble du système
• Cela provoque une "inflation" des points de stockage en raison du fait qu'un travail supplémentaire doit être effectué avec chaque ticket. Cela réduit la quantité de travail qui peut être effectuée à chaque sprint.

Révisions majeures du code

Ci-dessus, j'ai parlé de la stratégie de remboursement de la dette technique en remplaçant progressivement des parties du système, comme dans l' expérience de réflexion avec le vaisseau de Theseus , mais que se passe-t-il si cela ne suffit pas? Que faire si vous n'avez pas le temps de remplacer tout le logiciel pièce par pièce et que vous avez besoin de faire des changements plus radicaux?



Voici quelques idées pour vous aider:

Diviser une application en applications plus petites

Avec cette méthodologie, nous divisons l'application monolithique en applications plus petites. Souvent, cette approche est complétée par une conception basée sur le domaine et / ou des microservices, mais son point principal est que si l'application est trop grande pour être remplacée, elle peut être divisée en parties plus petites, dont le remplacement est réaliste, après quoi vous pouvez remplacer chaque partie l'une après l'autre.



Vous pouvez également implémenter ce schéma à l'aide du modèle Strangler Application de Martin Fowler, qui crée une nouvelle application qui reçoit les mêmes demandes que l'ancienne et effectue des appels aux systèmes hérités jusqu'à ce qu'un remplacement moderne soit prêt pour chacun d'entre eux.



Avantages:

:

• ,

capacity

Dans ce modèle, les développeurs peuvent utiliser le temps ou le temps alloué à la dette technique pour travailler sur des projets à long terme, tels que le remplacement d'une partie ou de la totalité d'une application. Une fois que des progrès suffisants ont été réalisés et que le travail peut être démarré sérieusement, ces tâches commencent à être implémentées dans une série de sprint ou de sprint pour une mise en œuvre et une livraison formelles.



En suivant ce modèle, j'ai réussi à porter des applications JavaScript sur TypeScript , y compris en passant du temps en dehors du travail (pas nécessairement, mais j'ai décidé de le faire) et en attendant que les environnements de test de régression soient mis en ligne.



Avantages:

• Les prototypes potentiellement défectueux qui ne sont pas liés aux cycles formels d'AQ / d'approvisionnement peuvent être identifiés et traités
• Lorsque le travail est prêt à être inclus dans le sprint, il s'agit déjà généralement d'un travail très concentré dans lequel la plupart des variables inconnues sont résolues.

Moins:

• Il peut être difficile de trouver une quantité significative de temps de prototypage hors calendrier, sauf si votre organisation souhaite réduire l'allocation des ressources à d'autres projets.

Transition complète vers la nouvelle application

Dans ce modèle, tout le travail sur l'ancienne application s'arrête, à l'exception de la correction des bogues critiques, et le travail commence sur l'application, qui deviendra son remplacement complet. C'est ce que les gens veulent généralement dire lorsqu'ils parlent de réécrire une application.



Avantages:

• Les employés peuvent se concentrer sur le nouveau système sans vraiment considérer l'existant.
• Le temps d'exécution total peut être inférieur

Moins:

• Avec des délais de livraison très courts, l'entreprise peut avoir l'impression de gaspiller de l'argent sur le projet.
• Les retards dans les délais peuvent interférer avec la livraison des travaux requis
• En fait, cette approche se transforme en principe du tout ou rien.
• Peut ne pas prendre pleinement en compte tous les risques avant d'investir dans un nouveau projet de plateforme

résultats

Considérez ces options pour mettre à jour continuellement les applications, ainsi que des options plus radicales. À mon avis, il n'y a pas de meilleure option, vous devez rechercher celle qui est la plus optimale pour votre équipe, votre produit et votre organisation. Évaluez ces approches et déterminez les options qui vous conviennent le mieux lors de la préparation d'une «rotation des cultures» pour garder votre base de code saine sur le long terme.