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

Et pourtant, meilleur sera le code contribué, plus courte sera la maintenance dessus. 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, d’horaires) qui font qu’on peut être amené à coder vite, ou à mal nettoyer des éléments inutiles. 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. Ou au moins de ne pas essayer.

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 peut retrouver sa place.