Les erreurs de débutant

Il y a plusieurs erreurs typiques faites par tous les informaticiens débutants. Jusque là, pas de soucis ; on fait tous des erreurs, c’est normal, ça fait partie du processus d’apprentissage.

Ce qui m’énerve, c’est que je vois de temps en temps des informaticiens expérimentés (5 ans d’expérience au moins) continuer à faire le même genre d’erreurs. C’est crispant, parce que ça démontre que la personne n’a pas cherché à s’améliorer professionnellement.

Parmi toutes ces erreurs, j’en ai listé quatre principales (plus une cinquième pour le plaisir).

1. Rock’n roll, baby

Beaucoup de jeunes développeurs ne prennent pas le temps de réfléchir un minimum à ce qu’il vont coder. Ils se jettent directement dans le code, écrivent ce qui leur passe par la tête, le modifie, font des ajouts, re-modifient, complètent, renomment, re-re-modifient, et ainsi de suite.

À l’école, quelque soit la formation, il est demandé de réussir les projets. La manière d’y arriver n’est pas vraiment enseignée. La plupart du temps, on commence par écrire les choses comme elles viennent. Et au fur et à mesure qu’on emmagasine de l’expérience, on comprend qu’il vaut mieux se poser d’abord quelques questions. Si on a la tête bien faite, on finit par réfléchir à nos développements en terme d’architecture logicielle, et non plus seulement en terme de «bouts de codes qui fonctionnent».

Concrètement, dans mon entreprise, je ne demande pas à mes développeurs d’écrire des spécifications techniques de 300 pages avant chaque développement. Je ne leur impose pas de me faire des diagramme UML pour représenter les objets et leurs interactions.
Pourquoi ? Simplement parce que, dans une démarche agile, je sais que les développeurs vont gagner en compétence et en expérience pendant leur développement. Il ne sert à rien de vouloir graver dans le marbre l’ensemble des spécifications, car on risque de “sortir des clous” dès la première méthode du premier objet.

Par contre, il me semble absolument nécessaire d’avoir une certaine idée de «là où on va». On va sûrement changer de direction en cours de développement. Mais si on se lance bille en tête sans avoir la moindre vision directrice, on risque de tourner en rond. Le code va ressembler à un immonde plat de spaghetti, inefficace et impossible à maintenir.

2. Documentation

Ce point est un peu lié au précédent. Souvent, les jeunes développeurs ont tendance à ne jamais documenter leur code. Cela provient de plusieurs choses :

• Ils pensent pouvoir garder éternellement en tête l’ensemble des informations relatives au code qu’ils écrivent. Bien souvent, ils n’ont eu à opérer que sur du code dont la durée de vie allait de quelques jours à quelques mois. Mais le jour où ils se retrouvent à maintenir du code écrit 1 an et demi auparavant, ça leur fait tout bizarre.
• Ils considèrent − à juste titre − qu’un développeur doit pouvoir lire du code source de manière fluide, comme un texte écrit dans une langue étrangère. Ainsi, il suffit de relire le code pour comprendre ce qu’il fait. Sauf que l’effort intellectuel est quand même bien plus important si on n’a pas un minimum d’informations sur le contexte dans lequel opère le code en question. C’est une perte de temps.
• Ceux qui sont le plus de mauvaise foi se justifient en disant que les noms de leurs objets, de leurs méthodes et de leurs variables sont suffisamment parlants pour ne pas avoir besoin de donner d’explications supplémentaires. Il est évident que les noms doivent être significatifs. Mais ils ne peuvent pas, à eux seuls, expliquer réellement à quoi sert le code, quels sont ses cas d’erreur et comment ils sont gérés, dans quels cas certains paramètres sont optionnels.

Je considère qu’il y a 2 manières de documenter le code : La documentation (au format JavaDoc, PHPDoc, Doxygen, POD, …) qui explique à quoi sert un objet et chacune de ses méthodes. Et les commentaires dans le code, pour expliquer comment fonctionne certains algorithmes un peu complexes. D’un côté le quoi (toujours), de l’autre le comment (au besoin).
Pour reboucler avec le point précédent, écrire la documentation avant d’écrire le code devrait être la toute première étape de codage. Si un développeur n’est pas capable d’écrire la doc d’une méthode avant d’en écrire le contenu, c’est qu’il n’y a pas réfléchi, et donc qu’il risque de faire n’importe quoi.

On pourra m’objecter que l’un des rôles des tests unitaires est justement de documenter le code testé. Oui et non. Oui, parce que les tests permettent de préciser l’environnement technique d’exécution du code (surtout dans le cadre de TDD). Mais non, car lorsque vous devez utiliser une librairie, vous voulez pouvoir vous référer à une documentation technique claire. Vous voulez savoir quel objet utiliser, quelle méthode appeler, quels paramètres lui fournir et qu’est-ce que vous allez obtenir en retour. Vous n’avez pas envie d’avoir besoin de lire le code des tests unitaires pour comprendre le code de la librairie (autant lire directement le code de la librairie).

3. Tester et communiquer !

Ah, ça c’est le truc le plus énervant. Les développeurs qui sont uniquement intéressés par l’aspect créatif du développement. Leur truc, c’est d’ajouter des fonctionnalités, de produire du code. Par contre, s’assurer que le code fait ce qu’il a à faire, ça implique de tester, de vérifier ; il faut exécuter des programmes, faire des requêtes en base de données, cliquer partout dans son navigateur, réfléchir à tous les cas bizarres qu’on a tenté de gérer dans le code.

Et ça, c’est fatiguant. C’est clairement pas passionnant. Ça manque de panache. C’est chiant.
Oui, mais il faut le faire. Parce qu’un développement qui ne fonctionne pas, ça ne sert à rien. Et la définition de ce qui fonctionne, c’est à vérifier auprès du client ; les excuses du genre «Ah, mais tout est correct en base de données !» ne cessent de me sidérer lorsqu’il aurait suffit d’un simple test humain en conditions réelles pour voir que fonctionnellement ça ne marche pas.

L’autre chose, c’est le syndrome du génie solitaire, qui fait les choses dans son coin, sans jamais parler à qui que ce soit. Vous avez 2 possibilités :

1. Le gars qui est complètement autiste. Tout le monde voit bien que le mec bosse comme un fou, sauf qu’il ne dit jamais quand il a fini un truc. Si vous faites quelque chose et que vous êtes le seul à être au courant, c’est comme si vous n’aviez rien fait.
2. Le gars qui ne dit rien tant qu’il développe, et qui montre fièrement son travail une fois terminé. Merci pour l’effet tunnel ; il y aura toujours 2 chances sur 3 pour qu’il ait pris une mauvaise direction à un moment ou un autre, et qu’on lui fasse refaire une partie du boulot.

4. Pourquoi faire simple ?

C’est peut-être l’erreur de débutant qui a tendance à persister le plus longtemps chez les développeurs. Et c’est l’erreur la moins pardonnable chez un développeur expérimenté.

Un assez grand nombre d’informaticiens prennent systématiquement le parti de la complexité. Ils ne veulent pas ou ne peuvent pas prendre le chemin le plus simple et le plus direct pour arriver à leurs fins. Cela peut prendre 2 formes différentes :

• Les algorithmes inutilement compliqués, qui partent dans tous les sens, qui font des traitements sur des traitements sur des traitements. La plupart du temps, c’est lié à un manque de réflexion de la part du développeur (cf. point numéro 1). Comme il n’a pas pensé à la direction qu’il voulait donner à son développement, il se retrouve à aller dans un sens, puis voyant que ça ne fonctionne pas, il ajoute une couche de code supplémentaire ; pour peu que ce va et vient ait lieu plusieurs fois, et on se retrouve avec du code bon à jeter.
• L’excès de zèle, qui pousse certaine personne à prendre en compte des demandes d’évolutions fonctionnelles fantômes. Parce qu’ils ont imaginé une fonctionnalité, ou qu’ils ont entendu telle ou telle personne dire que «ce serait bien si on avait ci ou ça», ils s’embrouillent l’esprit et pervertissent les choix techniques. Même lorsqu’on leur dit de se concentrer sur le développement demandé, même quand on leur explique qu’il ne sert à rien de prévoir un truc qui ne sera pas implémenté (ou bien qui aura pris une forme très différente le jour où on voudra l’implémenter), ils n’arrivent pas à se focaliser sur ce qu’ils ont à faire. C’est comme ça qu’on peut se retrouver avec du code huit fois trop gros, trop lent, avec plein de trucs inutiles qui le rendront très difficile à maintenir et à faire évoluer.

5. Normalisation

Nous avons tous des habitudes de codage. Elles dépendent de nos goûts personnels, de ce à quoi on a été habitué, de l’environnement technique dans lequel on évolue.

En entreprise (et cela est valable aussi pour les projets open-source importants), on ne peut pas se permettre d’avoir autant de manières d’écrire du code qu’il y a de développeurs. Il faut unifier les choses, pour réduire l’effort intellectuel nécessaire lorsqu’on se plonge dans le code écrit par quelqu’un d’autre. C’est pour ça qu’il existe deux grands types de normes :

• Les normes de codage, qui définissent la manière dont est écrit le code source. Cela peut concerner les règles d’indentation, de retour à la ligne, la taille des fonctions. Ça peut aussi concerner l’organisation des sources dans les répertoires des projets.
• Les normes de nommage, qui définissent les règles de choix et d’écriture des noms de variables, de méthodes, d’objets, de fichiers, de champs dans la base de données. Il faut aussi souvent des normes concernant les révisions et les tags dans les outils de gestion de source.

Quand on est jeune, on a rarement envie de se plier à la norme en place. On trouve toutes les bonnes raisons de la planète pour dire que notre norme est meilleure ; et que la norme utilisée est forcément obsolète puisqu’elle est vieille de plusieurs années. Je le sais bien, j’avais ce genre de raisonnement durant mon premier stage ; puis j’ai compris les bienfaits de ces normes, et maintenant je m’attache à mettre en place les normes offrant le meilleur équilibre entre le consensus (qui en facilitera l’adoption) et la direction technique choisie (car toute norme oriente forcément la vision des développements qui l’utilisent).

Addendum

En me relisant, je me rend compte que l’ensemble de l’article est très orienté «développement». Mais tout ce que j’ai écrit reste entièrement valable pour d’autres types de carrières en informatique. Ainsi, un administrateur système devra réfléchir avant d’agir, il devra documenter correctement son travail, devra tester (!), suivre les normes tout en gardant son infrastructure simple à comprendre. Que vous soyez webdesigner, rédacteur technique, technicien hotline ou domoticien, vous aurez les mêmes contraintes.