Reprendre un code, c’est toujours folklorique
Coucou les geeks,
Je ne code pas ou très peu mais les devs que j’ai côtoyé ont un point commun : ils n’aiment pas mettre le nez dans du "vieux code" que ce soit celui d’un collègue ou même le leur ! C’est plutôt amusant 😊
Le grand cycle du jugement
Tu ouvres un fichier en te disant que ça ne devrait pas être trop compliqué. Après trois lignes, tu fronces les sourcils. Après dix, tu lâches un soupir. Après trente, tu maudis l’auteur.
Tu lances un git blame
.
…
C’EST TOI.
C’est là que commence la phase d’auto-trahison. D’abord, tu nies. Ensuite, tu cherches une excuse. Et enfin, tu acceptes… à contrecœur.
Et si c’est le code d’un autre ? Pire. Tu vas immédiatement juger ses choix, peu importe qu’il ait eu des contraintes, une deadline, ou un manque de sommeil.
Pourquoi on trouve toujours que le code des autres est mauvais
1️⃣ Ce n’est pas notre logique
On a tous notre manière d’écrire du code. Il y a ceux qui nomment leurs variables avec précision (nombreUtilisateursActifs
), et ceux qui balancent un vague x
. Ceux qui commentent tout, et ceux qui estiment que "le code se lit tout seul".
Peu importe le style, dès qu’il ne correspond pas au tien, il te semble bancal.
2️⃣ Il manque toujours un bout d’explication
Tu ouvres une fonction et tu sens qu’elle fait un truc bizarre. Pourquoi ce if
est là ? Pourquoi ce bout de code semble ne servir à rien ? Tu regardes les commentaires… ah non, il n’y en a pas.
Les rares indications présentes ne sont pas franchement rassurantes :
// Hack temporaire
(il est là depuis trois ans)// J’espère que ça ne cassera pas
(ça a cassé)// Ne surtout pas toucher
(mais pourquoi ??)
3️⃣ On juge avant d’essayer de comprendre
Dès qu’un dev tombe sur un code qui ne lui plaît pas, son premier réflexe est rarement de chercher à comprendre pourquoi il a été écrit comme ça. Il préfère directement s’indigner :
- "C’est quoi cette horreur ?!"
- "Mais qui a eu cette idée absurde ?"
- "Franchement, ça ne m’étonne même pas."
On aime bien avoir un coupable. Parfois, c’est un collègue. Parfois, c’est soi-même.
Quand un dev réalise que c’est SON code
1️⃣ La mauvaise foi immédiate
💬 "C’est pas moi, c’est pas possible."
💬 "Le git blame doit être cassé."
💬 "Quelqu’un a dû modifier mon code après coup."
Premier réflexe : rejeter la faute sur quelqu’un d’autre.
2️⃣ L’auto-justification
💬 "Ouais bon, j’avais une deadline."
💬 "À l’époque, je ne savais pas mieux."
💬 "C’était temporaire… enfin, c’était censé l’être."
On ne peut pas se permettre d’accepter qu’on ait volontairement écrit un truc aussi douteux.
3️⃣ Le pragmatisme total
💬 "Bon, ça tourne en prod, donc je touche pas."
💬 "Je vais juste ajouter un commentaire pour prévenir les autres de ne pas y toucher non plus."
💬 "Si personne ne s’est plaint, c’est que ça va."
Si ça marche, autant ne pas trop creuser.
4️⃣ L’éveil du développeur
💬 "OK, c’était moche, mais j’ai compris pourquoi."
💬 "Je vais refactorer et ajouter une doc cette fois."
💬 "Je vais essayer… enfin, si j’ai le temps."
Cette prise de conscience arrive généralement après plusieurs années et quelques traumatismes en prod.
Quand tu reprends le code d’un autre dev
Tu lances le fichier.
Tu regardes le premier bloc de code.
Tu secoues la tête.
💬 "Pourquoi il a fait ça comme ça ?"
💬 "C’est quoi cette techno, ça fait cinq ans qu’on ne l’utilise plus."
💬 "Ah tiens, encore un truc que personne n’a documenté."
Et pourtant, ce code fonctionne. Pas de bug, pas d’incident. Alors, que fais-tu ?
- Option 1 : Laisser tomber, personne ne doit savoir ce que tu as vu.
- Option 2 : Tout réécrire. Mais ça prendra du temps, et tu risques d’introduire de nouveaux bugs.
- Option 3 : Ajouter un commentaire très vague, pour donner l’impression que quelqu’un a compris ce qui se passe ici.
À ce stade, il ne reste qu’une seule question : est-ce que quelqu’un va penser tout ça de ton code la prochaine fois ?
La réponse est évidente.
C'est des lignes et des lignes encore des lignes qui a son importance mais c'est faire toutes les relations qui est fou
J'avais un confrère qui me disait que si, on a toujours le choix.
Et je pense que, cela dépend des boîtes et deadlines liées.
Et je suis partisan du faire le code le plus clean possible.
Je préfère tant que possible éviter le "C'est degueu mais ça marche, on refactorisera plus tard".