Dans le livre Les 97 choses qu’un développeur devrait savoir, Mike Lewis a écrit un article traitant de la factorisation du code, ou la manière de mieux agencer le code pour une meilleure maintenabilité.
Voici cette article :
Tout le monde ayant une expérience dans l’industrie a sans aucun doute travaillé sur un projet où la base de code était précaire au mieux. Le système est mal factorisé, et changer une chose aura toujours pour effet de casser une autre caractéristique non liée. Chaque fois qu’un module est ajouté, l’objectif du codeur est de changer aussi peu que possible et de retenir son souffle pendant chaque sortie. C’est l’équivalent du logiciel de Jenga avec I-beams dans un gratte-ciel, et est destiné à un désastre.
La raison pour laquelle les changements sont tellement énervant est parce que le système est malade. Il a besoin d’un médecin, sinon sa condition ne fera que s’aggraver. Vous savez déjà ce qui ne va pas avec votre système, mais vous avez peur de briser les œufs pour faire votre omelette. Un chirurgien qualifié sait que des coupes doivent être faites pour fonctionner, mais elle sait aussi que les coupes sont temporaires et guérissent. Le résultat final de l’opération vaut la peine initiale, et le patient doit guérir à un meilleur état qu’il ne l’était avant la chirurgie.
N’ayez pas peur de votre code. Qui se soucie si quelque chose se brise temporairement pendant que vous déplacez les choses? Une peur paralysante du changement est ce que votre projet a commencé dans cet état. Investir du temps de refactoring plusieurs fois sur le cycle de vie de votre projet, paiera sur le long terme. Un avantage supplémentaire est que l’expérience, de votre équipe traitant du système malade, vous fera tous des experts, sur le comment du fonctionnement. Appliquer cette connaissance plutôt que de la repousser. Travailler sur un système que vous détestez n’est pas une bonne méthode à avoir pour passer son temps.
Redéfinir les interfaces internes, restructurer les modules, factoriser le code copié et simplifier votre conception en réduisant les dépendances. Vous pouvez réduire de manière significative la complexité du code en éliminant les cas d’angle, qui résultent souvent de caractéristiques couplées incorrectement. Transformez lentement l’ancienne structure en une nouvelle, en testant tout le long du chemin. Essayer d’accomplir une grande refactorisation dans «un grand boum» causera des problèmes suffisants pour que vous envisagiez d’abandonner tout l’effort à mi-parcours.
Soyez le chirurgien qui n’a pas peur de couper les parties malades pour amorcer la guérison. L’attitude est contagieuse et inspirera les autres à commencer à travailler sur les projets de nettoyage qu’ils ont abandonnés. Gardez une liste d’amélioration des tâches que l’équipe juge valables pour le bien général du projet. Convaincre la direction que, bien que ces tâches ne produisent pas de résultats visibles, elles réduiront les dépenses et accéléreront les versions futures. N’arrêtez jamais de prendre soin de la «santé» générale du code.
