Récemment il m’est venu à l’idée, dans un but ludique évidemment, de compiler quelques-uns des défauts les plus couramment rencontrés chez les développeurs. Ce n’est pas une liste exhaustive ni même une charge en règle contre les miens, mais plutôt une espèce d’introspection, d’auto-critique. En effet, quel développeur aurait la prétention de dire qu’il n’a jamais été la victime, consentante ou pas, d’ au moins un des points listés ci-dessous ?

1 – Le test…en prod !

Les fonctionnalités sont testées à la va-vite dans un coin par le développeur avant d’être parachutées sans pitié en production. Après tout, on ne teste jamais mieux qu’en condition réelle, n’est-ce pas ? Le (mauvais) développeur n’a jamais entendu parler des tests unitaires, fonctionnels ou d’intégration. Pour lui, le test est un processus visant à démontrer que tout marche à merveille, qu’il a fait du bon travail ! Non, c’est justement tout le contraire : le test est un processus AGRESSIF ! Alors évidemment, des bugs vont survenir en production et le développeur ira les corriger directement sur le serveur, à grands coups de Ctrl+S ou bien, à peine moins sale, en passant autant de fois que nécessaire des branches de hotfixes !

2 – L’appétit vorace pour la salade de technologies

Très fréquente chez les jeunes développeurs et principalement dans le milieu du développement web. On utilise des outils à la mode, sans trop chercher à connaître leur niveau de maturité, leur fréquence de mise à jour ou leur résistance à de fortes charges, une fois déployés. Tout le monde en parle et ces technos font le buzz sur des forums très fréquentés, c’est forcément qu’il y a une raison : il nous FAUT les avoir !!! Le code finit par ressembler à une grande marmite dans laquelle on aurait jeté tous les ingrédients trouvé sur les étagères de la cuisine et à terme le code va se retrouver emprisonné dans un écosystème de développement trop hétérogène et qui n’est pas sans rappeler la jungle…C’est une dérive du principe DRY (Don’t Repeat Yourself); comme tout a (presque) déjà été fait, on se contente d’agréger des outils tierce-partie sans forcément en mesurer toutes les conséquences. Ne vous rendez pas inutilement dépendants des autres : si ça existe et que c’est éprouvé, prenez ! Sinon, prenez…le temps de le faire !

3 – Le code zombie (qui ne meurt jamais vraiment)

Même lorsque certains développeurs travaillent avec des outils de gestion des versions (SVN, Git), ils conservent la mauvaise habitude de commenter des pavés de code entiers, comme s’ils voulaient garder tout ça « au cas où »…Le vieux code n’est d’aucune utilité, et encore moins si vous utilisez du version control ! Vivez et laissez mourir !

4 – Le freinage technique

Le développeur qui est réfractaire au changement constitue un frein technique. Cette fossilisation des pratiques dans des temps reculés (le cambrien ?) est pénalisante pour le reste de l’équipe. Il le sait, mais l’évolution n’est pas la première de ses préoccupations : il a souvent connu l’époque des langages procéduraux et ne voit pas bien l’intérêt de toutes ces choses « nouvelles » qui sont selon lui des lubies de programmeurs inexpérimentés (« Les objets ne sont que des containers passifs de données », « Les classes ne servent à rien », « Les contraintes d’intégrité référentielles contraignent trop le schéma des données »…). Son adage favori ?

Ça marche, alors on ne touche pas !

5 – Le nommage inconsistant des variables

Le (mauvais) développeur ne voit pas trop ce qu’on gagne à donner des identifiants « parlants » à des variables. S’il pouvait toutes les appeler « variable », il le ferait volontiers ! S’il a besoin de matérialiser une assurance, il appellera sa variable « a » : a comme assurance, enfin ! Et puis si demain les cas d’utilisation mettent en évidence la nécessité d’avoir 3 assurances et bien qu’à cela ne tienne, il créera a2 et a3 ! J’ai vu de tout personnellement; des objets nommés o, des booléens nommés b et même des variables portant le nom des personnes qui les avaient créées…les identifiants de variable doivent être courts et évocateurs !

6 – L’absence d’optimisation

Quand on écrit une requête SQL, pourquoi se préoccuper du temps qu’elle prend à s’exécuter ? Elle est syntaxiquement correcte et fait (à peu près) le job et puis ça sert à quoi les ORM ? On leur fait aveuglément confiance et tout se passera bien, ils sont faits pour ça ! De même pour le cache web, c’est géré par une couche dédiée à ça dans mon framework favori alors pourquoi devrai-je en plus m’intéresser à tout cela, j’ai déjà bien assez de travail comme ça ! Attention à ce genre de négligences quand on travaille sur des environnements à fort taux de charge ! Ne vous contentez pas de tourner la clé du véhicule et de l’utilisez, ouvrez le capot pour tirer le maximum de bénéfices de vos outils et des bonnes pratiques de développement !

7 – Le refus catégorique de la documentation

Le (mauvais) développeur pense qu’il est bon et c’est bien là le drame ! Pour lui, il suffit de lire son (excellent) code pour que tout apparaisse soudainement évident aux yeux de ses camarades codeurs qui vont avoir à reprendre son travail. La documentation c’est compliqué, il faut mettre des mots sur ce que l’on a fait, détailler, éventuellement justifier des choix…Ne négligez pas cette étape, un développeur qui ne documente pas ce qu’il fait, c’est du savoir qui va potentiellement s’évaporer !

8 – Le copier/coller comme méthode de développement

La programmation par Ctrl+C/Ctrl+V est un mal qui sévit depuis toujours…A quoi bon réfléchir, il suffit de dupliquer les choses autant de fois qu’il sera nécessaire. Et la maintenance ? Et les 10 classes à passer en revue à la moindre modification ? L’abus de Ctrl+C/Ctrl+V fait perdre 10 fois plus de temps que ce qu’il en fait gagner, mais on ne s’en rend compte souvent que des mois ou des années après; cette façon de faire est une véritable bombe à retardement, génératrice de dette technique !

9 – L’obsession de la centralisation

Le (mauvais) développeur croit comprendre que, pour limiter les modifications à tout va quand le temps du changement sera venu, il suffit simplement de tout mettre au même endroit ! Ses classes sont des monolithes de 3000 lignes qui font tout à la fois.

10 – L’euphorie de la découverte

Elle se produit lorsque le développeur trouve de nouveaux outils; quand il découvre les classes abstraites, il veut en mettre de partout, idem quand il découvre l’héritage, les fonctions statiques ou les designs patterns. Lorsque la solution est trouvée avant le problème, rien de bon ne peut en résulter. Souvenez-vous de cet adage populaire :

Quand tout ce qu’on a comme outil c’est un marteau, on a tendance à voir tous les problèmes comme des clous