La solution-a-la-dette-technique

Fabrice Aimetti
Fabrice AimettiDirigeant Ayeba (non certifié) à Ayeba

La solution à la dette technique

La Solution à la Dette Technique
Etes-vous dans une équipe de développement logiciel, qui essaie d'être agile? La prochaine fois
que votre équipe sera réunie, demandez-leur:
Comment voyez-vous la qualité de notre code ?
Chacun notera alors cette qualité dans une échelle de 1 à 5, où 5 signifie “Elle est superbe, j'en
suis fier!” et 1 veut dire “Merde totale”. Comparez. Si vous voyez une majorité de 4 et 5, et rien
en dessous de 3, alors ne tenez pas compte du reste de l'article.
Si vous apercevez de gros écarts, par exemple des 5 et des 1, alors vous devez vous y pencher. Est
ce que les notes sont différentes sur des parties de code différentes? Si oui, pourquoi la qualité est-
elle si différente ? Est ce que les notes sont différentes sur le même code ? Si oui, que veut dire le
mot qualité pour chaque équipier ?
Cependant, il plus probable que vous voyiez plutôt un lot de 2 ou moins, et très peu de 4 et 5. Le
terme pour cela est Dette Technique, pour les besoins de cet article je vais simplement l'appeler
Code Crade (Crappy Code).
Félicitations, vous venez tout juste de révéler un grave problème ! Vous l'avez même quantifié. Et
cela vous a peine pris une minute. N'importe qui peut faire cela, vous n'avez pas besoin d'être
Coach Agile ou Scrum Master. Allez-y, rendez-le aussi claire que du cristal – dessinez les
résultats sur un tableau blanc, mettez-les sur un mur. Visualiser un problème est un grand pas vers
sa résolution!
Ne vous inquiétez pas, vous n'êtes pas les seuls, c'est un problème très courant. <rant>Cependant,
c'est un problème tellement stupide et inutile que je suis souvent déconcerté du pourquoi il est si
banale.</rant>
Maintenant vous avez besoin de vous poser certaines questions difficiles.
Est-ce que nous voulons l'avoir dans cet état ?
Si c'est non, qu'est ce qui définit la qualité de code que nous voulons? La plupart des développeurs
veulent un niveau de qualité entre 4 et 5. Oui, l'échelle est arbitraire et subjective mais elle est
toujours utile.
Si les opinions varient fortement alors vous devez avoir une discussion sur ce que vous entendez
par qualité, et où voulez-vous être en tant qu'équipe. Vous pouvez utiliser les 4 règles d'un code
simple de Kent Beck comme point de départ. Il est difficile de résoudre le problème si vous n'êtes
pas d'accord sur où vous voulez être en tant qu'équipe.
Quel est la cause de ce problème?
C'est juste une question rhétorique parce que la réponse est claire.
“Les choses sont comme elles sont parce qu'elles ont été obtenues de cette façon!” - Jerry
Weinberg
La merde se trouve dans le code parce que les développeurs l'y ont mise ! Permettez-moi d'être le
plus clair possible à ce sujet: Le code crade est crée par les développeurs. Le développeur
utilise le clavier physique pour salir le code réel dans son ordinateur réel. Indépendamment de
certaines circonstances, ce sont bien les actions du développeur qui déterminent la qualité du code
La première étape d'une résolution de dette technique est d'admettre et d'accepter ce fait.
“mais attendez, nous avons hérité de tout un tas de code crade. Nous ne l'avons PAS écrit!”
OK, très bien. La question pertinente dans ce cas est : “Est ce que la qualité du code s'améliore ou
s'empire?” Notez cela dans une échelle de 5 points (où 1 veut dire “s'empire très vite”, 5 veut dire
“s'améliore très vite”). Ensuite ré-appliquez cet article sur la base de cette question.
Pourquoi nous produisons du code crade ?
La réponse varie. Cependant, je l'ai posé plusieurs fois et j'ai vu de très fortes tendances.Ce n'est
probablement pas parce que vous VOULEZ écrire du code crade. Je n'ai jamais rencontré encore
un développeur qui aimait écrire du code crade.
Ce n'est probablement pas parce que vous ne savez pas écrire du code propre (ou nettoyé). Les
compétences peuvent varier, mais il suffit que vous ayez quelques personnes compétentes en
écriture de code propre dans l'équipe, et une volonté des autres à apprendre. Combinez cela avec
une habitude de revue de code ou de programmation par pairs, et la plupart des équipes seront
parfaitement capables d'écrire du code qui sera noté entre 4 et 5, s'ils prennent le temps dont ils ont
besoin pour cela.
Cela peut être dû au syndrome de la fenêtre cassée. Le code crade invite à encore plus de code
crade, parce que les gens ont tendance à adapter le nouveau code à partir de la qualité de celui qui
y est déjà présent (“quand on est à Rome…”). Une fois vous avez compris cela, vous pouvez
décidez simplement d'Arrêter ça, et de commencer à faire des revues de code, de la
programmation par pairs pour vous en protéger.
Cependant, la raison la plus probable sur pourquoi vous écrivez du code crade est: La Pression.
J'ai souvent entendu des commentaires du genre “On n'a pas le temps décrire du code propre”
(<rant>cette déclaration est au pire un mensonge, au mieux une excuse boiteuse</rant>). La
vérité, vous avez 24 heures par jour comme tout le monde, et c'est à vous de savoir ce que vous en
faites avec. Faites face à ça. Vous avez du temps pour écrire du code propre, mais vous décidez de
ne pas le faire. Maintenant continuons à examiner ce concept de Pression.
D'où provient la pression?
Vous pourriez vouloir faire une analyse de causes à effet. Est ce que le product owner vous met la
pression ? Pourquoi ? Qui met la pression sur le product owner ? Qui met la pression sur la
personne qui met la pression sur le product owner ? Dessiner la chaîne de pression.
Ensuite demandez-vous. Est ce que cette pression est réelle ? Est ce que ces personnes veulent
vraiment que nous écrivions du code crade ? Connaissent-ils les effets d'un code crade (Je parie
que vous pouvez en lister énormément), et pensent-ils vraiment que cela vaut la peine d'en écrire ?
Probablement non. Allez-y, levez-vous et allez demander.
Parfois la cause même de la pression est les développeurs eux-mêmes. Développer une
fonctionnalité prend presque toujours plus de temps que nous le pensons, et nous voulons
réellement être un BON développeur et rendre les parties prenantes contentes, alors la pression
s'accumule de l'intérieur.
REMARQUE: parfois il y a un sens "business" d'écrire du code crade. Parfois la dette technique is
Bonne. Nous avons peut-être un objectif court-terme très important et critique, qu'il faut atteindre
à tout prix, ou nous voulons peut être construire un prototype jetable pour tester rapidement le
marché. Mais cela doit être l'exception, pas la norme. Si vous nettoyer le bazar que vous avez mis
dès que l'objectif court-terme est atteint, ou que vous jetiez réellement le prototype, alors vous ne
finirez pas avec un cas chronique de code crade.
Devons-nous décider d'arrêter ce non-sens maintenant ?
C'est la question la plus importante.
Si vous êtes développeurs, le fait que vous (en tant que développeur) soyez responsable du
problème est en fait une Bonne Nouvelle. Parce que cela veut dire que vous êtes parfaitement
capable de Résoudre le problème. Et la solution est simple:
Arrêter d'écrire du Code Crade
(tout juste ce que le monde avait besoin – un nouveau sigle: SWCC™)
En anglais : Stop Writing Crappy Code
“mais mais mais mais mais…. on n'a pas le temps… le PO bla bla bla, la date de release bla bla”
Non, épargnez-moi vos excuses. Juste Arrêtez-ça.
Bien OK, vous pourriez effectivement décider de continuer à écrire du code crade. Vous pourriez
décider qu'il vaut mieux ne pas se battre dans cette bataille. C'est votre décision. Si oui, ne vous
faites pas appeler "équipe de développement agile" au moins, et contestez quiconque qui pourrait
penser que vous êtes agiles. L'un des principes fondamentaux du développement logiciel agile est
un Rythme Soutenable. Si vous créez constamment du Code Crade, le développement va devenir
de plus en plus lent avec le temps. Il n'y a pas de sens "business" dans ça, et ce n'est certainement
pas agile.
Mais en partant du principe que vous voulez arrêter, explorons ce qui arrive.
En tant qu'équipe de développeurs, vous pouvez prendre position: “Nous allons arrêter d'écrire
du code crade”! Ecrivez le sur le mur. Serrez-vous la main sur ça. Ajoutez “Ne plus ajouter de
dette technique” dans votre Définition de fini (DoD).
Dites au monde, et au gens en qui vous croyez et qui vous mettent la pression dans le codage:
“Nous avons écrit du code crade. Désolé pour ça. Nous allons arrêter maintenant.” Essayez de le
dire haut et fort. ça fait du bien !
Arrêter d'écrire du Code Crade
Regardez ces deux courbes.
Oui, c'est simpliste, mais la différence est réelle. Si vous continuez à écrire du code crade, vous
allez ralentir de plus en plus avec le temps (vous allez passer de plus en plus de temps à vous
battre avec le code existant). Si vous arrêtez d'écrire du code crade, vous aurez un rythme plus
soutenable. Mais il y aura un coût sur votre vélocité – vous irez moins vite à court terme.
En tant qu'équipe, vous décidez combien de travail vous pouvez planifier – que le principe de
planification par tirage (pull-scheduling) est fondamental dans Agile et Lean. Il est intégré dans
les méthodes agiles. Par exemple, dans la planification de Sprint de Scrum, l'équipe choisit
combien d'éléments du backlog elle peut tirer dans un sprint, comme sur le Planning Game de la
méthode XP. Dans Kanban, l'équipe a une limite de travail en cours (work-in-progress limit) et
tire seulement le prochain élément quand le courant est fini. Fondamentalement, l'équipe a tout le
pouvoir et la responsabilité sur la qualité. Utilisez votre pouvoir !
En terme concrets: Si vous faites du Scrum, et que vous livrez environ 8-10 fonctionnalités par
sprint, essayer de réduire ça. Mettez seulement 6 histoires au prochain sprint, malgré toute
pression perçue. Demandez-vous à chaque rétrospective. “Quelle est la qualité du code que nous
avons produit dans ce sprint (échelle 1-5)”. Si c'est moins que 4-5, alors tirez moins d'histoires
dans le prochain sprint. Continuez à faire cela jusqu'à ce que vous obteniez un rythme soutenable.
Cela a des répercutions coté "business" bien sûr. Le product owner (ou quelque ce soit la personne
qui fixe les priorités business) devra prioriser plus difficilement. Elle était habituée à voir 8-10
histoires sortir à chaque sprint. Maintenant elle verra seulement 6 ou 7, alors elle devra décider
quelles histoires ne PAS faire.
Oui, cela mènera à des arguments et discussions dures. La réelle source de pression (s'il y en a) se
révélera d'elle même. La Qualité est invisible à court terme, et cela doit être expliqué. Prenez la
bataille ! Restez fidèle à vos décisions. Si les développeurs ne veulent pas prendre la
responsabilité de leur code, qui le fera ?
La qualité du Code n'est pas la qualité du Produit
Le Code n'est pas tout. Il y a plus de gens impliqués dans le développement de produit
qu'uniquement les développeurs. Il y a les analystes métier, les testeurs, les managers, les
administrateurs système, les designers, les opérateurs, DRH, et plus.
Chacun est collectivement responsable de la qualité du produit qui sera fabriqué. Cela n'inclut pas
seulement le code, le design graphique, la structure de base de données, et les artefacts statiques
comme ça. Cela inclut aussi bien l'expérience utilisateur toute entière comme résultat business du
produit.
La qualité du Code est un sous-ensemble de la qualité du produit. Vous pouvez avoir un super
code, mais toujours finir avec un produit que personne ne veut utiliser car il résout le mauvais
problème.
Et vice versa – pouvez-vous avoir un super produit, mais avec un code crade ? J'ai horreur de
l'admettre mais, Oui, techniquement vous pouvez construire un super produit avec un code crade.
D'une certains manière, les équipes semblent s'en tirer parfois. Par contre, améliorer et maintenir
le produit est lent, coûteux, et difficile, parce que le produit est pourri de l'intérieur. C'est une
proposition perdant-perdant et sur le long terme les meilleurs développeurs partent.
Qu'en est il du vieux code crade (a.k.a Legacy Code)?
OK, alors vous venez d'arrêter d'écrire du code crade. Félicitations ! Vous venez d'arrêter
d'accumuler de la dette technique. Vous continuerez à payer des intérêts sur votre dette existante,
mais au moins la dette a arrêté de grossir.
La prochaine étape à décider – pouvez-vous vivre avec la dette technique existante, ou voulez-
vous faire quelque chose sur ça ? Si vous décidez de réduire la dette technique, la conséquence est
que vous allez ralentir encore plus à court terme, mais accélérer sur le long terme. Comme ceci:
Parfois cela en vaut la peine, parfois non. La réponse n'est pas aussi évidente, c'est une décision
business, alors assurez-vous d'impliquer les gens qui sont payés pour ça.
Si vous décidez de réduire votre dette technique courante, faites-en une décision claire: “Nous
allons arrêter d'écrire du code crade, et nettoyer progressivement le vieux code”.
Une fois que vous êtes d'accord sur ça (et c'est la partie difficile), il y a plein de techniques sur
comment faire. Voici deux techniques que j'ai vu marcher particulièrement bien:
1. Ajouter à la Définition de Fini: “Dette Technique réduite”. Cela veut dire dès que vous
fabriquez une fonction ou que vous touchez du code, vous le laissez dans un meilleur état
que vous l'avez trouvé. Cela peut être renommer une méthode pour la rendre plus claire, ou
factoriser certains bouts de code dupliqués dans une méthode partagée. De petites étapes.
Mais si l'équipe entière (ou encore mieux, toutes les équipes) fait cela constamment, la
qualité du code va s'améliorer significativement en quelques mois.
2. Pour les zones plus grandes à nettoyer, créer un “backlog technique” & un temps réservé
pour ça. Par exemple, listez le top 10 des zones d'amélioration et engagez vous à en corriger
un chaque semaine ou sprint, avant de construire de nouvelles fonctions.
Il suffit de garder à l'esprit que, si vous le faites, repayer la dette signifie moins de fonctionnalités
à court terme. Adaptez vos prévisions de vélocité de plans de release en conséquence. Comme tout
investissement, il y a un coût à court terme. Assurez-vous que chacun est clair sur ça.
Vous devez Ralentir pour Accélérer.
Mot de la Fin
Essentiel : la qualité du code est la responsabilité des gens qui écrivent réellement le code
(autrement connu sous le nom de Développeurs).
En tant que développeur, je suis responsable du problème, et je suis responsable de la solution. Il
n'est pas nécessaire de se fâcher ou d'avoir honte du passé. Au lieu de cela, rester fier et utiliser
votre pouvoir de faire quelque chose sur ça – prendre une lourde décision d'Arrêter d'Ecrire du
Code Crade (SWCC). Cela commence avec une chaîne d’événements et de bonnes choses vont
probablement suivre sur le long terme. C'est difficile et cela demande du courage, mais je connais
aucun autre moyen pour résoudre la dette technique.
Bonne chance!
/Henrik
FAQ
Est ce que la dette technique est toujours mauvaise?
Non. Avoir un peu de dette peut être bon. Voir mon autre article Bonne et Mauvaise Dette
Technique (et comment le TDD aide).
Le problème dont je parle ici est chronique, hors-de-contrôle, faisant grossir continuellement la
dette. J'ai vu tant d'entreprises se noyer dans de la dette technique, avançant lentement avec peine,
perdant leurs développeurs clés, et regrettant amèrement de ne pas avoir pris soin de la qualité de
leur code sérieusement dès le début, car ça coûte tellement plus cher de le réparer par la suite.
Couper la qualité donne des bénéfices court terme, mais le long terme est plus long que le court
terme, et la plupart des entreprises souhaitent survivre sur le long terme.
Qu'est ce que c'est la dette technique ?
N'importe quel bout de code & environnement de développement qui vous ralentit. Par exemple:
• Code illisible, pas clair.
• Manque de tests automatisés, de fabrication automatisée, de déploiement automatisée, et
tout autre chose qui pourrait être automatisé que vous faites manuellement aujourd'hui.
• Code dupliqué.
• Architecture bancale & dépendances complexes inutiles.
• Outils inefficaces, lents.
• Code non validé & branches longues (long-lived) (qui caches des problèmes qui pourrait
vous ralentir plus tard).
• Documentation technique importante qui manque ou n'est pas à jour.
• Documentation technique inutile qui est maintenue et gardée à jour.
• Manque d'environnements de test.
• Long cycle de test et de fabrication & manque d'intégration continue.

Recommandé

Mesurez votre libido agile par
Mesurez votre libido agileMesurez votre libido agile
Mesurez votre libido agileNicholas Suter
1.5K vues57 diapositives
Tester votre libido Agile par
Tester votre libido AgileTester votre libido Agile
Tester votre libido AgileCellenza
3.6K vues57 diapositives
Développer en mode kick-ass à Devoxx France par
Développer en mode kick-ass à Devoxx FranceDévelopper en mode kick-ass à Devoxx France
Développer en mode kick-ass à Devoxx FranceSamuel Le Berrigaud
2.3K vues115 diapositives
Mob programming 101 @Morpho (Groupe Safran) - 08/03/2016 par
Mob programming 101 @Morpho (Groupe Safran) - 08/03/2016Mob programming 101 @Morpho (Groupe Safran) - 08/03/2016
Mob programming 101 @Morpho (Groupe Safran) - 08/03/2016André De Sousa
777 vues36 diapositives
Et si on jouait au tdd 20131017 par
Et si on jouait au tdd 20131017Et si on jouait au tdd 20131017
Et si on jouait au tdd 20131017François-Xavier Maquaire
847 vues52 diapositives
Le Bootstrapping : Ou comment monter un MVP fonctionnel en quelques heures - ... par
Le Bootstrapping : Ou comment monter un MVP fonctionnel en quelques heures - ...Le Bootstrapping : Ou comment monter un MVP fonctionnel en quelques heures - ...
Le Bootstrapping : Ou comment monter un MVP fonctionnel en quelques heures - ...André De Sousa
1.4K vues66 diapositives

Contenu connexe

Tendances

Sortir de l’ère des héros - HumanTalks Paris Mars 2017 par
Sortir de l’ère des héros - HumanTalks Paris Mars 2017Sortir de l’ère des héros - HumanTalks Paris Mars 2017
Sortir de l’ère des héros - HumanTalks Paris Mars 2017Jean-Pierre Lambert
491 vues19 diapositives
Article Kanban vs Scrum par
Article Kanban vs ScrumArticle Kanban vs Scrum
Article Kanban vs ScrumFabrice Aimetti
1.6K vues26 diapositives
Introduction aux spécifications exécutables (dit aussi atdd, bdd) par
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Jean-Pierre Lambert
1.9K vues56 diapositives
Agile Methodologies par
Agile MethodologiesAgile Methodologies
Agile MethodologiesJean-Philippe Jacoupy
874 vues43 diapositives
Démarrer en Kanban par
Démarrer en KanbanDémarrer en Kanban
Démarrer en KanbanFabrice Aimetti
998 vues7 diapositives
Kanban vs Scrum (slides) par
Kanban vs Scrum (slides)Kanban vs Scrum (slides)
Kanban vs Scrum (slides)Fabrice Aimetti
1.1K vues41 diapositives

Tendances(19)

Sortir de l’ère des héros - HumanTalks Paris Mars 2017 par Jean-Pierre Lambert
Sortir de l’ère des héros - HumanTalks Paris Mars 2017Sortir de l’ère des héros - HumanTalks Paris Mars 2017
Sortir de l’ère des héros - HumanTalks Paris Mars 2017
Introduction aux spécifications exécutables (dit aussi atdd, bdd) par Jean-Pierre Lambert
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD par DC CONSULTANTS
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDDWebinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
Webinar - Mieux s'entendre entre Dev / PO / Testeur avec TDD et BDD
DC CONSULTANTS162 vues
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions par AgileCoach.net
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisionsDevoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
AgileCoach.net3.9K vues
Apprendre java script facilement par Léo Arnoux
Apprendre java script facilementApprendre java script facilement
Apprendre java script facilement
Léo Arnoux107 vues
Human Talks Grenoble - 11/12/2012 - TDD par Xavier NOPRE
Human Talks Grenoble - 11/12/2012 - TDDHuman Talks Grenoble - 11/12/2012 - TDD
Human Talks Grenoble - 11/12/2012 - TDD
Xavier NOPRE2.4K vues
Accélérer les tests d’acceptation avec un DSL et du refactoring par Laurent PY
Accélérer les tests d’acceptation avec un DSL et du refactoringAccélérer les tests d’acceptation avec un DSL et du refactoring
Accélérer les tests d’acceptation avec un DSL et du refactoring
Laurent PY2.3K vues
Kanban et Scrum : tirer le meilleur des deux par Fabrice Aimetti
Kanban et Scrum : tirer le meilleur des deuxKanban et Scrum : tirer le meilleur des deux
Kanban et Scrum : tirer le meilleur des deux
Fabrice Aimetti2.1K vues
Kanban pour maîtriser le développement incrémental par Fabrice Aimetti
Kanban pour maîtriser le développement incrémentalKanban pour maîtriser le développement incrémental
Kanban pour maîtriser le développement incrémental
Fabrice Aimetti997 vues
TDD (Test Driven Developement) et refactoring par neuros
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoring
neuros1.5K vues

Similaire à La solution-a-la-dette-technique

Synergie entre développeur et consultant SEO - Didier Sampaolo - SEOcamp'us P... par
Synergie entre développeur et consultant SEO - Didier Sampaolo - SEOcamp'us P...Synergie entre développeur et consultant SEO - Didier Sampaolo - SEOcamp'us P...
Synergie entre développeur et consultant SEO - Didier Sampaolo - SEOcamp'us P...SEO CAMP
2.4K vues19 diapositives
Synergies entre DEV et SEO (SeoCampus 2019) par
Synergies entre DEV et SEO (SeoCampus 2019)Synergies entre DEV et SEO (SeoCampus 2019)
Synergies entre DEV et SEO (SeoCampus 2019)LVLUP
270 vues19 diapositives
Les Bases des Méthodes Lean/Agile par
Les Bases des Méthodes Lean/AgileLes Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileAgileCoach.net
8.2K vues91 diapositives
Rédiger son cahier des charges - notes par
Rédiger son cahier des charges - notesRédiger son cahier des charges - notes
Rédiger son cahier des charges - notesConcept Image
67 vues137 diapositives
Développer en mode kick-ass à Scrum Day par
Développer en mode kick-ass à Scrum DayDévelopper en mode kick-ass à Scrum Day
Développer en mode kick-ass à Scrum DaySamuel Le Berrigaud
1.8K vues111 diapositives
Développement piloté par les tests - DDD par
Développement piloté par les tests - DDDDéveloppement piloté par les tests - DDD
Développement piloté par les tests - DDDPyxis Technologies
1.4K vues42 diapositives

Similaire à La solution-a-la-dette-technique(20)

Synergie entre développeur et consultant SEO - Didier Sampaolo - SEOcamp'us P... par SEO CAMP
Synergie entre développeur et consultant SEO - Didier Sampaolo - SEOcamp'us P...Synergie entre développeur et consultant SEO - Didier Sampaolo - SEOcamp'us P...
Synergie entre développeur et consultant SEO - Didier Sampaolo - SEOcamp'us P...
SEO CAMP2.4K vues
Synergies entre DEV et SEO (SeoCampus 2019) par LVLUP
Synergies entre DEV et SEO (SeoCampus 2019)Synergies entre DEV et SEO (SeoCampus 2019)
Synergies entre DEV et SEO (SeoCampus 2019)
LVLUP270 vues
Les Bases des Méthodes Lean/Agile par AgileCoach.net
Les Bases des Méthodes Lean/AgileLes Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/Agile
AgileCoach.net8.2K vues
Rédiger son cahier des charges - notes par Concept Image
Rédiger son cahier des charges - notesRédiger son cahier des charges - notes
Rédiger son cahier des charges - notes
Concept Image67 vues
Agile tour 2015 alliés contre les défauts par Julien Jakubowski
Agile tour 2015   alliés contre les défautsAgile tour 2015   alliés contre les défauts
Agile tour 2015 alliés contre les défauts
Julien Jakubowski3.5K vues
Agile tour Lille 2015 allies ensemble contre les defauts par Antoine Blk
Agile tour Lille 2015 allies ensemble contre les defautsAgile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defauts
Antoine Blk293 vues
Comment (mieux) rédiger mon cahier des charges ? par Concept Image
Comment (mieux) rédiger mon cahier des charges ? Comment (mieux) rédiger mon cahier des charges ?
Comment (mieux) rédiger mon cahier des charges ?
Concept Image133 vues
1001 techniques pour exploser un projet (et comment les éviter) par Goulven Champenois
1001 techniques pour exploser un projet (et comment les éviter)1001 techniques pour exploser un projet (et comment les éviter)
1001 techniques pour exploser un projet (et comment les éviter)
Comment (mieux) rédiger mon cahier des charges ? par Concept Image
Comment (mieux) rédiger mon cahier des charges ? Comment (mieux) rédiger mon cahier des charges ?
Comment (mieux) rédiger mon cahier des charges ?
Concept Image55 vues
Savoir déléguer efficacement par Teraformation
Savoir déléguer efficacementSavoir déléguer efficacement
Savoir déléguer efficacement
Teraformation317 vues
Software Craftsmanship par ylemoigne
Software CraftsmanshipSoftware Craftsmanship
Software Craftsmanship
ylemoigne2.4K vues
Mob Programming et #NoEstimates : contre-intuitif et efficace par Nicolas Umiastowski
Mob Programming et #NoEstimates : contre-intuitif et efficaceMob Programming et #NoEstimates : contre-intuitif et efficace
Mob Programming et #NoEstimates : contre-intuitif et efficace
Comment rédiger pour le web ? par Concept Image
Comment rédiger pour le web ?Comment rédiger pour le web ?
Comment rédiger pour le web ?
Concept Image293 vues
Mockito - Design + tests par Brice Duteil par Normandy JUG
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice Duteil
Normandy JUG996 vues
20131024 qualité de code et sonar - mug lyon par Clement Bouillier
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
Clement Bouillier3.3K vues

Plus de Fabrice Aimetti

Groupe de Balint par
Groupe de BalintGroupe de Balint
Groupe de BalintFabrice Aimetti
71 vues42 diapositives
La fabrique narrative marcela polanco par
La fabrique narrative marcela polancoLa fabrique narrative marcela polanco
La fabrique narrative marcela polancoFabrice Aimetti
300 vues61 diapositives
Beata Jardin de vie (Rwanda) par
Beata Jardin de vie (Rwanda)Beata Jardin de vie (Rwanda)
Beata Jardin de vie (Rwanda)Fabrice Aimetti
180 vues26 diapositives
Bibliographie narrative par
Bibliographie narrativeBibliographie narrative
Bibliographie narrativeFabrice Aimetti
5.2K vues24 diapositives
Arrêtez de promettre des miracles par
Arrêtez de promettre des miraclesArrêtez de promettre des miracles
Arrêtez de promettre des miraclesFabrice Aimetti
211 vues9 diapositives
20191126 conf-au-dela-de-la-prison par
20191126 conf-au-dela-de-la-prison20191126 conf-au-dela-de-la-prison
20191126 conf-au-dela-de-la-prisonFabrice Aimetti
2.8K vues66 diapositives

Plus de Fabrice Aimetti(20)

La fabrique narrative marcela polanco par Fabrice Aimetti
La fabrique narrative marcela polancoLa fabrique narrative marcela polanco
La fabrique narrative marcela polanco
Fabrice Aimetti300 vues
20191126 conf-au-dela-de-la-prison par Fabrice Aimetti
20191126 conf-au-dela-de-la-prison20191126 conf-au-dela-de-la-prison
20191126 conf-au-dela-de-la-prison
Fabrice Aimetti2.8K vues
20190627 intro-clean-language slideshare par Fabrice Aimetti
20190627 intro-clean-language slideshare20190627 intro-clean-language slideshare
20190627 intro-clean-language slideshare
Fabrice Aimetti714 vues
Agile self assessment card game by Ben Linders par Fabrice Aimetti
Agile self assessment card game by Ben LindersAgile self assessment card game by Ben Linders
Agile self assessment card game by Ben Linders
Fabrice Aimetti745 vues
Les 4 étapes du processus de la CNV par Fabrice Aimetti
Les 4 étapes du processus de la CNVLes 4 étapes du processus de la CNV
Les 4 étapes du processus de la CNV
Fabrice Aimetti2.7K vues
Le jeu du prénom en mode multitâche par Fabrice Aimetti
Le jeu du prénom en mode multitâcheLe jeu du prénom en mode multitâche
Le jeu du prénom en mode multitâche
Fabrice Aimetti1.5K vues

Dernier

FORMATION SUR LES PICTOGRAMMES DE SECURITE KKW.pptx par
FORMATION SUR LES PICTOGRAMMES DE SECURITE KKW.pptxFORMATION SUR LES PICTOGRAMMES DE SECURITE KKW.pptx
FORMATION SUR LES PICTOGRAMMES DE SECURITE KKW.pptxKOUADIO WILLIAMS KOUAME
9 vues17 diapositives
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23 par
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23Newsletter SPW Agriculture en province du Luxembourg du 13-11-23
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23BenotGeorges3
6 vues17 diapositives
Julia Margaret Cameron par
Julia Margaret Cameron Julia Margaret Cameron
Julia Margaret Cameron Txaruka
5 vues20 diapositives
Newsletter SPW Agriculture en province de LIEGE du 28-11-23 par
Newsletter SPW Agriculture en province de LIEGE du 28-11-23Newsletter SPW Agriculture en province de LIEGE du 28-11-23
Newsletter SPW Agriculture en province de LIEGE du 28-11-23BenotGeorges3
26 vues21 diapositives
Cours Audit General 2019 (1).prof tatouti .pdf par
Cours Audit  General 2019 (1).prof tatouti .pdfCours Audit  General 2019 (1).prof tatouti .pdf
Cours Audit General 2019 (1).prof tatouti .pdfAbdelghani19
7 vues230 diapositives
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23 (adapté au 2... par
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23 (adapté au 2...Newsletter SPW Agriculture en province du Luxembourg du 13-11-23 (adapté au 2...
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23 (adapté au 2...BenotGeorges3
24 vues18 diapositives

Dernier(15)

Newsletter SPW Agriculture en province du Luxembourg du 13-11-23 par BenotGeorges3
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23Newsletter SPW Agriculture en province du Luxembourg du 13-11-23
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23
BenotGeorges36 vues
Julia Margaret Cameron par Txaruka
Julia Margaret Cameron Julia Margaret Cameron
Julia Margaret Cameron
Txaruka5 vues
Newsletter SPW Agriculture en province de LIEGE du 28-11-23 par BenotGeorges3
Newsletter SPW Agriculture en province de LIEGE du 28-11-23Newsletter SPW Agriculture en province de LIEGE du 28-11-23
Newsletter SPW Agriculture en province de LIEGE du 28-11-23
BenotGeorges326 vues
Cours Audit General 2019 (1).prof tatouti .pdf par Abdelghani19
Cours Audit  General 2019 (1).prof tatouti .pdfCours Audit  General 2019 (1).prof tatouti .pdf
Cours Audit General 2019 (1).prof tatouti .pdf
Abdelghani197 vues
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23 (adapté au 2... par BenotGeorges3
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23 (adapté au 2...Newsletter SPW Agriculture en province du Luxembourg du 13-11-23 (adapté au 2...
Newsletter SPW Agriculture en province du Luxembourg du 13-11-23 (adapté au 2...
BenotGeorges324 vues
Formation M2i - Augmenter son impact en communication et en management grâce... par M2i Formation
Formation M2i - Augmenter son impact en communication et en management grâce...Formation M2i - Augmenter son impact en communication et en management grâce...
Formation M2i - Augmenter son impact en communication et en management grâce...
M2i Formation60 vues
Formation M2i - Cadre réglementaire des IA Génératives : premiers éléments de... par M2i Formation
Formation M2i - Cadre réglementaire des IA Génératives : premiers éléments de...Formation M2i - Cadre réglementaire des IA Génératives : premiers éléments de...
Formation M2i - Cadre réglementaire des IA Génératives : premiers éléments de...
M2i Formation20 vues
Présentation de lancement SAE105 par JeanLucHusson
Présentation de lancement SAE105Présentation de lancement SAE105
Présentation de lancement SAE105
JeanLucHusson121 vues
Julia Margaret Cameron par Txaruka
Julia Margaret CameronJulia Margaret Cameron
Julia Margaret Cameron
Txaruka74 vues
MNGTCOUT PROJET 04112023.pptx par HAIDI2
MNGTCOUT PROJET 04112023.pptxMNGTCOUT PROJET 04112023.pptx
MNGTCOUT PROJET 04112023.pptx
HAIDI26 vues

La solution-a-la-dette-technique

  • 1. La Solution à la Dette Technique Etes-vous dans une équipe de développement logiciel, qui essaie d'être agile? La prochaine fois que votre équipe sera réunie, demandez-leur: Comment voyez-vous la qualité de notre code ? Chacun notera alors cette qualité dans une échelle de 1 à 5, où 5 signifie “Elle est superbe, j'en suis fier!” et 1 veut dire “Merde totale”. Comparez. Si vous voyez une majorité de 4 et 5, et rien en dessous de 3, alors ne tenez pas compte du reste de l'article. Si vous apercevez de gros écarts, par exemple des 5 et des 1, alors vous devez vous y pencher. Est ce que les notes sont différentes sur des parties de code différentes? Si oui, pourquoi la qualité est- elle si différente ? Est ce que les notes sont différentes sur le même code ? Si oui, que veut dire le mot qualité pour chaque équipier ? Cependant, il plus probable que vous voyiez plutôt un lot de 2 ou moins, et très peu de 4 et 5. Le terme pour cela est Dette Technique, pour les besoins de cet article je vais simplement l'appeler Code Crade (Crappy Code). Félicitations, vous venez tout juste de révéler un grave problème ! Vous l'avez même quantifié. Et cela vous a peine pris une minute. N'importe qui peut faire cela, vous n'avez pas besoin d'être Coach Agile ou Scrum Master. Allez-y, rendez-le aussi claire que du cristal – dessinez les résultats sur un tableau blanc, mettez-les sur un mur. Visualiser un problème est un grand pas vers sa résolution! Ne vous inquiétez pas, vous n'êtes pas les seuls, c'est un problème très courant. <rant>Cependant, c'est un problème tellement stupide et inutile que je suis souvent déconcerté du pourquoi il est si banale.</rant> Maintenant vous avez besoin de vous poser certaines questions difficiles.
  • 2. Est-ce que nous voulons l'avoir dans cet état ? Si c'est non, qu'est ce qui définit la qualité de code que nous voulons? La plupart des développeurs veulent un niveau de qualité entre 4 et 5. Oui, l'échelle est arbitraire et subjective mais elle est toujours utile. Si les opinions varient fortement alors vous devez avoir une discussion sur ce que vous entendez par qualité, et où voulez-vous être en tant qu'équipe. Vous pouvez utiliser les 4 règles d'un code simple de Kent Beck comme point de départ. Il est difficile de résoudre le problème si vous n'êtes pas d'accord sur où vous voulez être en tant qu'équipe. Quel est la cause de ce problème? C'est juste une question rhétorique parce que la réponse est claire. “Les choses sont comme elles sont parce qu'elles ont été obtenues de cette façon!” - Jerry Weinberg La merde se trouve dans le code parce que les développeurs l'y ont mise ! Permettez-moi d'être le plus clair possible à ce sujet: Le code crade est crée par les développeurs. Le développeur utilise le clavier physique pour salir le code réel dans son ordinateur réel. Indépendamment de certaines circonstances, ce sont bien les actions du développeur qui déterminent la qualité du code La première étape d'une résolution de dette technique est d'admettre et d'accepter ce fait. “mais attendez, nous avons hérité de tout un tas de code crade. Nous ne l'avons PAS écrit!” OK, très bien. La question pertinente dans ce cas est : “Est ce que la qualité du code s'améliore ou s'empire?” Notez cela dans une échelle de 5 points (où 1 veut dire “s'empire très vite”, 5 veut dire “s'améliore très vite”). Ensuite ré-appliquez cet article sur la base de cette question. Pourquoi nous produisons du code crade ? La réponse varie. Cependant, je l'ai posé plusieurs fois et j'ai vu de très fortes tendances.Ce n'est probablement pas parce que vous VOULEZ écrire du code crade. Je n'ai jamais rencontré encore un développeur qui aimait écrire du code crade. Ce n'est probablement pas parce que vous ne savez pas écrire du code propre (ou nettoyé). Les compétences peuvent varier, mais il suffit que vous ayez quelques personnes compétentes en écriture de code propre dans l'équipe, et une volonté des autres à apprendre. Combinez cela avec une habitude de revue de code ou de programmation par pairs, et la plupart des équipes seront parfaitement capables d'écrire du code qui sera noté entre 4 et 5, s'ils prennent le temps dont ils ont besoin pour cela. Cela peut être dû au syndrome de la fenêtre cassée. Le code crade invite à encore plus de code crade, parce que les gens ont tendance à adapter le nouveau code à partir de la qualité de celui qui y est déjà présent (“quand on est à Rome…”). Une fois vous avez compris cela, vous pouvez décidez simplement d'Arrêter ça, et de commencer à faire des revues de code, de la programmation par pairs pour vous en protéger. Cependant, la raison la plus probable sur pourquoi vous écrivez du code crade est: La Pression. J'ai souvent entendu des commentaires du genre “On n'a pas le temps décrire du code propre”
  • 3. (<rant>cette déclaration est au pire un mensonge, au mieux une excuse boiteuse</rant>). La vérité, vous avez 24 heures par jour comme tout le monde, et c'est à vous de savoir ce que vous en faites avec. Faites face à ça. Vous avez du temps pour écrire du code propre, mais vous décidez de ne pas le faire. Maintenant continuons à examiner ce concept de Pression. D'où provient la pression? Vous pourriez vouloir faire une analyse de causes à effet. Est ce que le product owner vous met la pression ? Pourquoi ? Qui met la pression sur le product owner ? Qui met la pression sur la personne qui met la pression sur le product owner ? Dessiner la chaîne de pression. Ensuite demandez-vous. Est ce que cette pression est réelle ? Est ce que ces personnes veulent vraiment que nous écrivions du code crade ? Connaissent-ils les effets d'un code crade (Je parie que vous pouvez en lister énormément), et pensent-ils vraiment que cela vaut la peine d'en écrire ? Probablement non. Allez-y, levez-vous et allez demander. Parfois la cause même de la pression est les développeurs eux-mêmes. Développer une fonctionnalité prend presque toujours plus de temps que nous le pensons, et nous voulons réellement être un BON développeur et rendre les parties prenantes contentes, alors la pression s'accumule de l'intérieur. REMARQUE: parfois il y a un sens "business" d'écrire du code crade. Parfois la dette technique is Bonne. Nous avons peut-être un objectif court-terme très important et critique, qu'il faut atteindre à tout prix, ou nous voulons peut être construire un prototype jetable pour tester rapidement le marché. Mais cela doit être l'exception, pas la norme. Si vous nettoyer le bazar que vous avez mis dès que l'objectif court-terme est atteint, ou que vous jetiez réellement le prototype, alors vous ne finirez pas avec un cas chronique de code crade. Devons-nous décider d'arrêter ce non-sens maintenant ? C'est la question la plus importante. Si vous êtes développeurs, le fait que vous (en tant que développeur) soyez responsable du problème est en fait une Bonne Nouvelle. Parce que cela veut dire que vous êtes parfaitement capable de Résoudre le problème. Et la solution est simple: Arrêter d'écrire du Code Crade (tout juste ce que le monde avait besoin – un nouveau sigle: SWCC™) En anglais : Stop Writing Crappy Code “mais mais mais mais mais…. on n'a pas le temps… le PO bla bla bla, la date de release bla bla” Non, épargnez-moi vos excuses. Juste Arrêtez-ça. Bien OK, vous pourriez effectivement décider de continuer à écrire du code crade. Vous pourriez décider qu'il vaut mieux ne pas se battre dans cette bataille. C'est votre décision. Si oui, ne vous faites pas appeler "équipe de développement agile" au moins, et contestez quiconque qui pourrait penser que vous êtes agiles. L'un des principes fondamentaux du développement logiciel agile est un Rythme Soutenable. Si vous créez constamment du Code Crade, le développement va devenir de plus en plus lent avec le temps. Il n'y a pas de sens "business" dans ça, et ce n'est certainement pas agile.
  • 4. Mais en partant du principe que vous voulez arrêter, explorons ce qui arrive. En tant qu'équipe de développeurs, vous pouvez prendre position: “Nous allons arrêter d'écrire du code crade”! Ecrivez le sur le mur. Serrez-vous la main sur ça. Ajoutez “Ne plus ajouter de dette technique” dans votre Définition de fini (DoD). Dites au monde, et au gens en qui vous croyez et qui vous mettent la pression dans le codage: “Nous avons écrit du code crade. Désolé pour ça. Nous allons arrêter maintenant.” Essayez de le dire haut et fort. ça fait du bien ! Arrêter d'écrire du Code Crade Regardez ces deux courbes. Oui, c'est simpliste, mais la différence est réelle. Si vous continuez à écrire du code crade, vous allez ralentir de plus en plus avec le temps (vous allez passer de plus en plus de temps à vous battre avec le code existant). Si vous arrêtez d'écrire du code crade, vous aurez un rythme plus soutenable. Mais il y aura un coût sur votre vélocité – vous irez moins vite à court terme. En tant qu'équipe, vous décidez combien de travail vous pouvez planifier – que le principe de planification par tirage (pull-scheduling) est fondamental dans Agile et Lean. Il est intégré dans les méthodes agiles. Par exemple, dans la planification de Sprint de Scrum, l'équipe choisit combien d'éléments du backlog elle peut tirer dans un sprint, comme sur le Planning Game de la méthode XP. Dans Kanban, l'équipe a une limite de travail en cours (work-in-progress limit) et tire seulement le prochain élément quand le courant est fini. Fondamentalement, l'équipe a tout le pouvoir et la responsabilité sur la qualité. Utilisez votre pouvoir ! En terme concrets: Si vous faites du Scrum, et que vous livrez environ 8-10 fonctionnalités par sprint, essayer de réduire ça. Mettez seulement 6 histoires au prochain sprint, malgré toute pression perçue. Demandez-vous à chaque rétrospective. “Quelle est la qualité du code que nous
  • 5. avons produit dans ce sprint (échelle 1-5)”. Si c'est moins que 4-5, alors tirez moins d'histoires dans le prochain sprint. Continuez à faire cela jusqu'à ce que vous obteniez un rythme soutenable. Cela a des répercutions coté "business" bien sûr. Le product owner (ou quelque ce soit la personne qui fixe les priorités business) devra prioriser plus difficilement. Elle était habituée à voir 8-10 histoires sortir à chaque sprint. Maintenant elle verra seulement 6 ou 7, alors elle devra décider quelles histoires ne PAS faire. Oui, cela mènera à des arguments et discussions dures. La réelle source de pression (s'il y en a) se révélera d'elle même. La Qualité est invisible à court terme, et cela doit être expliqué. Prenez la bataille ! Restez fidèle à vos décisions. Si les développeurs ne veulent pas prendre la responsabilité de leur code, qui le fera ? La qualité du Code n'est pas la qualité du Produit Le Code n'est pas tout. Il y a plus de gens impliqués dans le développement de produit qu'uniquement les développeurs. Il y a les analystes métier, les testeurs, les managers, les administrateurs système, les designers, les opérateurs, DRH, et plus. Chacun est collectivement responsable de la qualité du produit qui sera fabriqué. Cela n'inclut pas seulement le code, le design graphique, la structure de base de données, et les artefacts statiques comme ça. Cela inclut aussi bien l'expérience utilisateur toute entière comme résultat business du produit. La qualité du Code est un sous-ensemble de la qualité du produit. Vous pouvez avoir un super code, mais toujours finir avec un produit que personne ne veut utiliser car il résout le mauvais problème. Et vice versa – pouvez-vous avoir un super produit, mais avec un code crade ? J'ai horreur de l'admettre mais, Oui, techniquement vous pouvez construire un super produit avec un code crade. D'une certains manière, les équipes semblent s'en tirer parfois. Par contre, améliorer et maintenir le produit est lent, coûteux, et difficile, parce que le produit est pourri de l'intérieur. C'est une proposition perdant-perdant et sur le long terme les meilleurs développeurs partent. Qu'en est il du vieux code crade (a.k.a Legacy Code)? OK, alors vous venez d'arrêter d'écrire du code crade. Félicitations ! Vous venez d'arrêter d'accumuler de la dette technique. Vous continuerez à payer des intérêts sur votre dette existante, mais au moins la dette a arrêté de grossir. La prochaine étape à décider – pouvez-vous vivre avec la dette technique existante, ou voulez- vous faire quelque chose sur ça ? Si vous décidez de réduire la dette technique, la conséquence est que vous allez ralentir encore plus à court terme, mais accélérer sur le long terme. Comme ceci:
  • 6. Parfois cela en vaut la peine, parfois non. La réponse n'est pas aussi évidente, c'est une décision business, alors assurez-vous d'impliquer les gens qui sont payés pour ça. Si vous décidez de réduire votre dette technique courante, faites-en une décision claire: “Nous allons arrêter d'écrire du code crade, et nettoyer progressivement le vieux code”. Une fois que vous êtes d'accord sur ça (et c'est la partie difficile), il y a plein de techniques sur comment faire. Voici deux techniques que j'ai vu marcher particulièrement bien: 1. Ajouter à la Définition de Fini: “Dette Technique réduite”. Cela veut dire dès que vous fabriquez une fonction ou que vous touchez du code, vous le laissez dans un meilleur état que vous l'avez trouvé. Cela peut être renommer une méthode pour la rendre plus claire, ou factoriser certains bouts de code dupliqués dans une méthode partagée. De petites étapes. Mais si l'équipe entière (ou encore mieux, toutes les équipes) fait cela constamment, la qualité du code va s'améliorer significativement en quelques mois. 2. Pour les zones plus grandes à nettoyer, créer un “backlog technique” & un temps réservé pour ça. Par exemple, listez le top 10 des zones d'amélioration et engagez vous à en corriger un chaque semaine ou sprint, avant de construire de nouvelles fonctions. Il suffit de garder à l'esprit que, si vous le faites, repayer la dette signifie moins de fonctionnalités à court terme. Adaptez vos prévisions de vélocité de plans de release en conséquence. Comme tout investissement, il y a un coût à court terme. Assurez-vous que chacun est clair sur ça. Vous devez Ralentir pour Accélérer. Mot de la Fin Essentiel : la qualité du code est la responsabilité des gens qui écrivent réellement le code (autrement connu sous le nom de Développeurs). En tant que développeur, je suis responsable du problème, et je suis responsable de la solution. Il
  • 7. n'est pas nécessaire de se fâcher ou d'avoir honte du passé. Au lieu de cela, rester fier et utiliser votre pouvoir de faire quelque chose sur ça – prendre une lourde décision d'Arrêter d'Ecrire du Code Crade (SWCC). Cela commence avec une chaîne d’événements et de bonnes choses vont probablement suivre sur le long terme. C'est difficile et cela demande du courage, mais je connais aucun autre moyen pour résoudre la dette technique. Bonne chance! /Henrik FAQ Est ce que la dette technique est toujours mauvaise? Non. Avoir un peu de dette peut être bon. Voir mon autre article Bonne et Mauvaise Dette Technique (et comment le TDD aide). Le problème dont je parle ici est chronique, hors-de-contrôle, faisant grossir continuellement la dette. J'ai vu tant d'entreprises se noyer dans de la dette technique, avançant lentement avec peine, perdant leurs développeurs clés, et regrettant amèrement de ne pas avoir pris soin de la qualité de leur code sérieusement dès le début, car ça coûte tellement plus cher de le réparer par la suite. Couper la qualité donne des bénéfices court terme, mais le long terme est plus long que le court terme, et la plupart des entreprises souhaitent survivre sur le long terme. Qu'est ce que c'est la dette technique ? N'importe quel bout de code & environnement de développement qui vous ralentit. Par exemple: • Code illisible, pas clair. • Manque de tests automatisés, de fabrication automatisée, de déploiement automatisée, et tout autre chose qui pourrait être automatisé que vous faites manuellement aujourd'hui. • Code dupliqué. • Architecture bancale & dépendances complexes inutiles. • Outils inefficaces, lents. • Code non validé & branches longues (long-lived) (qui caches des problèmes qui pourrait vous ralentir plus tard). • Documentation technique importante qui manque ou n'est pas à jour. • Documentation technique inutile qui est maintenue et gardée à jour. • Manque d'environnements de test. • Long cycle de test et de fabrication & manque d'intégration continue.