Envoyé par
rmaker
Tu prends le cas d'une vieille appli, mais ce n'est même pas la peine d'aller aussi loin. La dette technique dans mon cas de pauvre petit développeur en banque finance... (une histoire de rmaker, aux "éditions de la ss2i dans la joie")
Dans un monde idéal, on écrit les tests, on code, on teste, on refactore. Les tests garantissent que le refactoring ne casse pas une fonctionnalité importante. Et on refactor tellement qu'on n'a plus de dette technique. Si on met cette bonne pratique dès le début du projet, ça passe. C'est facile.
Mais, évidemment, personne ne fait ça. Chez nous, on code, on ne teste pas, et évidemment, on ne refactor pas. Pas le temps. Du coup, des classes bien pensées au début vont prendre des responsabilités en plus, parce que ' la modif c'est là, et point barre' et que c'est plus simple. Quête de la solution la plus rapide rime avec 0 refacto. Le code devient donc des énormes classes qui ont une responsabilité bien trop grosse (elles gèrent les connexions à la base, les requêtes, et une partie du métier par exemple) et des classes de merde autour. Dette technique à fond, et ça va très vite. Mais alors, TRES vite.
Et donc, quelle est notre réponse? Et bien on paie les intérêts de la dette technique à chaque nouvelle itération. Réponse du client? Ce n'est pas grave!
Car au bout d'un moment, le code est tellement pourri que la première modif prend des mois. Donc, on est hors budget sur le projet. Donc, le projet ne sert à rien. Donc, le pauvre chef de projet est déplacé / viré / recasé, et son équipe est dissoute. Comme c'est du presta, ça part bien. Une nouvelle équipe est reformée. Elle a pour but de remplacer l'outil précédent, celui qui est en train de crever de sa dette technique. Et donc, la nouvelle application a du budget, commence à coder proprement, et etc, l'histoire se poursuit...
Voilà... Je sais que je n'ai pas vendu du rêve, et pourtant, c'est vrai.
Partager