Je souhaite dans cet article étudier des cas de dette technique [1], concept introduit par Ward Cunningham en 1992, et partager les solutions trouvées pour éviter d’arriver à un surendettement technique, obligeant une refonte qui est malheureusement parfois obligatoire.
Ayant travaillé principalement chez des éditeurs de logiciels à l‘époque que les moins de 20 ans ne peuvent pas connaître, j’ai récupéré un historique (entre cent et deux cent mille lignes), une documentation lacunaire, voire inexistante. Alors, imaginez à propos de la dette !
Je me suis retrouvé comme bon nombre de développeurs à changer de casquette, devenant spéléologue, géologue (code ayant des strates correspondant aux différentes personnes ayant contribué), voire profileur du FBI pour comprendre la logique, la psychologie de la personne ayant produit le code.
Dans cet article, je vais introduire le contexte des projets, leur historique. Comprendre le contexte, dans l’entreprise, d’un développement legacy permet de mieux saisir pourquoi cela a été fait ainsi, et peut aider à désamorcer la colère envers les anciens contributeurs …
- Accédez à tous les contenus de Connect en illimité
- Découvrez des listes de lecture et des contenus Premium
- Consultez les nouveaux articles en avant-première
 
 
				 
					 
 
 
 
