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.