Vous êtes développeur ou développeuse et souhaitez donner la meilleure image de vous-même ? On vous présente 5 pièges dans lesquels vous ne devez pas tomber afin de briller dans votre travail !
Pour illustrer ces erreurs classiques, nous avons repris les superbes illustrations de Joel Hagai, dont les visuels percutants viennent donner encore plus de relief à ce Top 5.
1- Commencer à coder sans questionner le besoin
Une nouvelle demande vient d'arriver ! Chouette ! Vous allez pouvoir faire ce que vous savez faire de mieux : coder !
Belle erreur ! Le besoin exprimé brut est souvent imprécis. Il oriente parfois en toute bonne foi vers une solution technique en supposant souvent à tort que cela simplifiera la vie du développeur. Il imagine qu'elle sera la moins coûteuse ou la plus pérenne, mais n'ayant pas de connaissances techniques la solution proposée reste de l'intuition.
⚠️ Si le métier ne précise pas son besoin et se limite à proposer une solution, celui-ci risque de ne pas être complètement satisfait, et la maintenance peut ensuite s'avérer complexe.
Alors, quand vous recevez une demande, la première chose à faire est de vous demander :
✅ Pourquoi ?
✅ Quel est le besoin implicite ?
✅ Peut-on imaginer d'autres solutions ?
💡 Questionner le besoin avant de commencer à coder, c'est important !
2- Chercher la perfection a priori au lieu de la chercher a postériori
Mahalia : "Bon, Lucie, il faudrait que tu implémentes la factorielle s'il te plaît."
Lucie : "Rien de plus simple ! Si je prends un entier n alors factorielle(n) = n*factorielle(n-1) si n>1, sinon n"
Lucie code…
Elle tente de faire quelque chose de propre.
Si n est un entier, si n est un long, si n est un biginteger, si n n'est pas défini…
Mahalia : "Bon, que se passe-t-il si je lance factorielle (0) ?"
Lucie : "ça renverra 0"
Mahalia : "factorielle(0) = 1 tu sais…"
Et c'est reparti, Lucie modifie son code pour que factorielle (0) = 1. Elle doit également mettre à jour ses tests.
Mahalia : "Quel est le résultat de ton programme avec factorielle(-5) ?"
Lucie : "euh... -5 ?"
Mahalia : "Erreur encore ! Ce n'est pas défini... Ton programme devrait renvoyer une erreur !"
⚠️ Lucie a cherché à implémenter toute la factorielle d'un coup, sans découper le besoin en sous-besoins. Elle a essayé de fournir une implémentation parfaite immédiatement.
Le TDD (Test Driven Development) permet d'éviter cela. Dans cet exemple, il aurait été bon de commencer par se poser les questions suivantes :
✅ Que vaut factorielle(0) ?
✅ Que vaut factorielle(1) ?
✅ Sur quel ensemble cette fonction est-elle définie ?
L'implémentation aurait été incrémentale. La recherche de la "perfection" (dans le code) vient après l'implémentation du besoin élémentaire. Cela permet de s'assurer que le besoin est bien compris, qu'il est bien couvert par des tests, et que lorsque le code sera modifié et revu, les fonctionnalités et sous-fonctionnalités ne seront pas cassées.
💡 On fait les choses simples dans un premier temps, et on les fait évoluer ensuite.
3- Se décharger de la responsabilité du code une fois qu'il est poussé
Reprenons notre exemple précédent.
Mahalia : "Lucie, ton code fonctionnait, on l'a vu ensemble, par contre j'ai un cas qui vient d'arriver et qui donne un truc bizarre… Ton code prend un entier sur 32 bits et retourne un entier sur 32 bits… Quand je mets en entrée le nombre 2147483648, ça me donne un nombre négatif… Tu peux revoir ton code ?"
Lucie : "Attends, attends, le code a été validé par Elsa, la tech lead… Donc mon code était correct ! Si ça fait n'importe quoi, ce n'est pas ma faute ! Parles-en à Elsa directement si tu as un nouveau besoin."
⚠️ L'erreur de Lucie est de se mettre sur la défensive, comme si on l'attaquait personnellement.
Les bugs font partie du cycle de vie d'un projet. Lucie peut entendre "Tu as mal codé !", et elle se met sur la défensive. Lorsqu'ils se sentent attaqués, certains développeurs répondent au client "Sur mon poste ça marche...". Entendez : "Je ne sais pas ce que tu as fait, mais ça ne vient pas de mon code..."
Mahalia ne critique pas Lucie, au contraire, elle a besoin de Lucie pour que les choses avancent.
Son message : "Docteur, mon projet est malade, qu'est-ce qu'on peut faire ? C'est grave docteur ?". Imaginez que le docteur réponde : "Je l'ai soigné il y a un mois et il était en bonne santé ensuite ! Donc ce n'est pas ma faute !"
Bref, on ne demande pas à notre chère Lucie de prendre le point dans l'immédiat (car n'oublions pas qu'elle doit jongler entre les priorités), mais plutôt de rassurer Mahalia : "Ah, étrange ! Est-ce bloquant ? Remonte l'info en nous donnant toutes les précisions nécessaires et quelqu'un (moi, ou une personne de l'équipe) analysera. Ne t'en fais pas, on ne te laissera pas sans visibilité."
Il s'agit donc purement de relations humaines et de ressenti, de "soft skills" comme on dit. Ces petites choses peuvent permettre d'avancer tellement mieux !
💡 Le bon état d’esprit : être collaboratif et chercher à avancer ensemble. Cela fait partie des Soft Skills indispensables en tant que dev !
4- Créer des besoins et de la complexité inutiles
Voici le syndrome de la perfection, de l'over-engineering. Le développeur veut montrer qu'il est le meilleur, qu'il a tout prévu, et il fait autant cela dans le besoin métier que dans l'implémentation technique !
Voyons comment Lucie parvient à complexifier petit à petit le besoin métier.
Mahalia : "Lucie, j'aurais besoin que tu implémentes une méthode qui calcule le maximum de deux nombres."
Lucie : "D'accord, ces nombres, ce sont des entiers ? ou des nombres à virgule ?"
Mahalia : "Euh... Parfois ce seront des entiers, parfois des nombres à virgule."
Lucie : "Combien de chiffres après la virgule ?"
Mahalia : "Je ne sais pas, entre 2 et 5..."
"..."
Lucie enchaîne les questions, ajoutant des fonctionnalités inutiles... et elle implémentera :
- Une factory qui retourne un comparateur en fonction de la politique de comparaison définie par l'utilisateur (qui pourrait vouloir comparer les éléments de manière différente selon des critères spécifiques)
- Plusieurs méthodes max surchargées par type primitif et renvoyant ce type primitif
- Une méthode max qui prend des objets et le comparateur à appliquer
- Des méthodes "formattedMax" qui font la même chose mais retournent des chaines de caractères à des fins d'affichage
⚠️ Mahalia ne sait plus où donner de la tête et se dit que décidément, le développement n'est chose facile !
💡 Moralité : faites simple ! Un code clair et efficace vaut mieux qu’une usine à gaz !
5- Les commentaires dans le code !
Quand j'étais étudiant, les professeurs nous répétaient "commentez votre code !"
Il m'a fallu beaucoup de temps pour comprendre que c'était une mauvaise pratique dans la majorité des cas. Attention, on ne parle pas de documentation publique de code, mais bien des petits commentaires qu'on peut voir dans le code.
On voit parfois ceci :
// Returns the speed
public int getSpeed(){
return speed;
}
⚠️ Quel est le problème ?
- Ici le commentaire n'ajoute aucune information. La simple lecture du nom de la méthode permet de comprendre ce qu'elle fait sans avoir à commenter.
- Si le nom de la méthode n'est pas évident, ou que celle-ci a une complexité métier haute (la fameuse machine à café qui fait aussi les sodas, les brownies, et vous brosse les dents toute seule), alors il est fort probable que le code soit mal conçu.
Les langages de programmation haut niveau sont faits pour être lisible par des humains sans avoir besoin d'un artefact tel que le commentaire.
Nuançons ce propos
dans le cas de l'algorithmie, il peut être intéressant de commenter le code. Non-pas pour dire ligne par ligne ce qu'il fait (là encore, le code est supposé être lisible !), mais bien pour donner des informations sur l'algorithme : complexité, documentation externe, limites (mémoire, pile d'appels, etc...).
❔Mais alors, pourquoi demander aux étudiants de commenter le code ?
Les étudiants sont en formation. Le code qu'ils fournissent n'est donc pas forcément très propre. La propreté du code n'est pas le sujet de la matière enseignée, et le professeur peut avoir besoin des commentaires de l'étudiant pour comprendre ce qu'il a tenté de faire.
💡 Bonne pratique : un bon code doit être auto-documenté grâce à des noms explicites et une bonne structuration.
Conclusion
Le développement logiciel est un métier passionnant, mais aussi exigeant. Il ne se résume pas uniquement à écrire du code : il demande de la réflexion, de la communication et une approche méthodique pour éviter les pièges courants.
Vous avez désormais toutes les clés pour briller dans votre travail !
