Je ne maîtrise que le C++ mais je pense que le conseil de Erik Buck est valable pour tous les langages et que c'est le meilleur conseil que l'on puisse donner.
En effet, une bonne factorisation de code implique qu'à peu près tous les autres bon conseils et techniques de programmation soient exploités, notamment les conseils indiqués dans ce blog
Attention, je dis bien une bonne factorisation mais je n'en dirais pas plus sur ce que c'est car ce serait très long, il doit bien exister des bouquins là dessus.
La technique de (re)factorisation de code est cependant rarement utilisée dans un processus de développement en équipe :
- D'abord parce que la factorisation n'apporte pas de gain fonctionnel (le gain fonctionnel est le seul paramètre généralement pris en compte).
- Ensuite parce-qu'une tâche de (re)factorisation n'est pas facile à mettre en place et peut s'avérer dangereux si elle est mal réalisée :
- on peut facilement ajouter des bugs en factorisant,
- La factorisation implique souvent de modifier les interfaces et cela peut engendrer des modifications en cascade assez pénibles pour les autres développeurs (tout le monde vous tombe dessus )
Bref ce type de tâche est souvent remise aux calandres grecs :
1. Une équipe qui développe est très souvent à la bourre et n'a donc "pas le temps d'écrire du code correctement factorisé",
2. Une équipe qui rajoute une fonctionnalité sur un code précédemment écrit n'a pas été mandatée pour refactoriser ce code ancien, il rajoute une verrue et basta !
Bien souvent une refactorisation est mise en oeuvre "lorsque l'on a plus le choix" :
- le code est trop incompréhensible,
- la moindre modif de code doit être reportée à plusieurs endroits
Partager