J’aimerais avoir assez de temps pour refactor ce code !
Chaque semaine c’est la même histoire : vous devez toucher à ce code. Pour fixer un bug, ou pour changer un comportement, voire peut-être pour ajouter une toute nouvelle fonctionnalité.
Mais ce n’est pas vous qui avez écrit ce code !
C’est un bordel sans nom et mal documenté. Vous aimeriez bien refactor le code avant de le changer. Mais il n’y a aucun test ! Et donc vous n’avez pas trop envie de vous risquer à casser quelque chose en le refactorant… Vous vous êtes déjà fait avoir une fois, pas deux !
Alors oui, vous pourriez commencer par écrire les tests. Mais vous n’avez pas le temps ! Vous avez déjà trop de choses à faire dans le peu de temps qui vous a été imposé…
Et vous y voilà donc : vous êtes bloqué, parce que vous ne savez pas par quel bout le prendre. Devriez-vous commencer par nettoyer le code, quitte à risquer la deadline ? Et comment allez-vous faire pour écrire des tests sur du code qui n’a clairement pas été écrit pour être testé ?
Quand je commence à refactor un bout, y’a tout qui vient !
Vous avez déjà essayé de nettoyer le code, mais tout est complètement emmêlé !
Vous avez fait des progrès mais plus rien ne fonctionne. Vous ne pouvez donc pas vous arrêter maintenant… sauf qu’il est déjà 21h et votre famille vous attend ! 😡
Vous connaissez la suite…
Vous n’essayez même plus de comprendre ce chaos. Vous vous contentez de faire en sorte que Ça Marche©. C’est sale. Ce n’est pas si mal non plus. Vous avez croisé bien pire dans ce tas de code. Vous faites le boulot, quitte à aggraver la situation. Il faut livrer.
Vous aimeriez bien pouvoir tout recommencer à zéro. Mais ce serait difficile à négocier. Pas de temps, ni d’argent pour ce genre de projet.
Vous n’êtes pas très fier de cette base de code que vous maintenez. Mais bon, vous vous y habituez. Les clients demandent toujours plus de fonctionnalités, et vos collègues n’ont pas l’air de s’intéresser à la qualité du code. Vous avez l’impression de faire votre travail. Mais vous savez que vous pourriez faire mieux.
Cela dit, votre chef ne comprend pas pourquoi ça vous prend si longtemps de faire les changements demandés. Vous avez déjà essayé de lui expliquer, mais les deadlines sont toujours trop courtes et la priorité est toujours donnée à la livraison de nouvelles fonctionnalités. Tout le monde se fiche bien que vos yeux saignent en lisant ce code !
C’est fatigant ! 😫
Si vous pouviez au moins arrêter l’hémorragie…
Vous savez ce qui serait chouette ? Travailler avec du code propre et bien testé. Pas de mauvaise surprise, facile à modifier. Le rêve… That would be a breeze to work with…
Mais votre base de code à vous, c’est un champ de mine. Comment pourriez-vous espérer déminer des ANNÉES de Dette Technique ?!
Et si je vous disais qu’il existe des manières de refactor le code ET de respecter les deadlines ?
Imaginez que vous puissiez refactor le code tout en livrant des fonctionnalités. Imaginez que vous amélioriez l’état du code au fur et à mesure que vous revenez dessus, pour en faire un système facile à tester et à maintenir ! 🌱
Si vous connaissez les bons gestes, vous pouvez apporter les premiers soins à votre code et arrêter le massacre. À quel point seriez-vous fier de vous et soulagé de pouvoir redonner des couleurs à votre code ?
Bien sûr, le système que vous maintenez en ce moment est rempli de problèmes. Il a l’air de fonctionner, mais il ne survit vraiment qu’à travers des hacks et des patchs plus ou moins tordus. Parfois, vous vous demandez si ce ne serait pas plus simple de tout recommencer à zéro…
Mais qu’en serait-il si vous découvriez des techniques qui vous permettraient de le sauver ?
Imaginez pouvoir nettoyer votre Code Legacy à chaque fois que vous y touchez.
Peu importe l’état de votre code, vous saurez toujours par où commencer. En appliquant constamment les bonnes techniques, vous pourrez arrêter le carnage et éviter une refonte très coûteuse.
Mais surtout, vous continuerez de corriger des bugs et d’ajouter des fonctionnalités sans arrêt.
Vous n’avez pas à demander la permission de refactor quand vous êtes capable de le faire à la volée !
Le Refactoring deviendra une deuxième nature pour vous. Vos réflexes vous permettront de nettoyer n’importe quel Legacy plus rapidement que n’importe lequel de vos collègues ! Vous répondrez constamment aux attentes de vos clients et inspirerez vos pairs.
En fait, vous pouvez commencer à améliorer cette base de code la prochaine fois que vous y touchez. ✨
Quand les deadlines sont serrées, il est risqué d’essayer de refactor le code… à moins de savoir exactement ce que vous faites.
Grâce à ce guide de Premiers Soins, vous allez apprendre à refactor sans risque et rapidement.
J’ai collecté pour vous un ensemble de techniques qui vous aideront à reprendre le contrôle de votre code Legacy. Ce sont les trucs et astuces qui fonctionnent le mieux pour moi. Je les utilise quand je travaille sur des projets en production qui manquent (évidemment) de tests et de docs (ça vous semble familier ?).
Ces 14 mouvements vous aideront à :
- optimiser votre travail pour avoir le maximum d’impact
- identifier ce qui rend le code difficile à tester
- rapidement installer un filet de sécurité sur le code que vous devez toucher
- améliorer la qualité du code progressivement
- livrer à chaque instant !
