Nous sommes tous de mauvais développeurs dans la mesure où aucun code n’est parfait et où les habitudes des uns ne sont pas celles des autres. Ceci étant dit, ce n’est pas une raison pour ne pas faire attention à la qualité du code qu’on contribue. La qualité de code n’est pas réservée à un responsable donné, pendant une campagne donnée.
Le problème, sur un projet massif, est que personne n’ose modifier le code parce que :
- cela entraîne un risque de régression ;
- l’intégrer en branche supérieure devient plus fastidieux ;
- on ne veut pas vexer la personne qui a fait le développement à l’origine ;
- on attend les outils (ou leur mise-à-jour) permettant d’industrialiser la relecture de code afin d’être plus efficaces…
La liste est longue. Pourtant, meilleur sera le code contribué, plus légère sera la maintenance. En réduisant la surface de code sur laquelle des erreurs sont possibles, on limite les risques de bugs mais ce n’est pas tout : en cas d’erreur, la relecture d’un code bien écrit facilitera l’identification et la correction.
Tout le problème réside dans l’égo des développeurs car personne n’aime se dire (et pire, se faire dire) qu’il a mal codé. Pourtant, avoir développé un code améliorable n’est pas mal coder. Nous avons tous des impératifs (de temps, de charges, de couverture fonctionnelle) qui font qu’on peut être amené à coder vite, ou à mal nettoyer des éléments superflus. Il ne faut pas juger les gens sur ça. Ce qui est mauvais, en revanche, c’est de savoir que le code est mauvais et de ne rien faire pour changer les choses.
On arrive là sur un problème qui n’est plus véritablement un problème technique mais davantage un problème d’éthique du développeur et c’est là que l’égo devrait retrouver sa place.