Je vais vous raconter une petite histoire qui devrait vous sembler familière. Cette légende est célèbre, et connue de tous les développeurs. Certains même en tremblent à sa seule évocation, ou en cauchemardent lors des nuits les plus noires. Pour ceux qui dormaient au fond, Je vais vous rafraîchir la mémoire.

Il était une fois un développeur répondant au nom de Dave Lawper. Le brave Dave devait corriger un bug au fin fond d’une librairie propriétaire que personne n’avait osé touché depuis la nuit des temps.

Après avoir cherché pendant des heures et vidé plusieurs tasses de café, le pauvre hère était dans un état de lassitude avancé. Les lignes de codes s’alignaient les unes après les autres, copiées et dupliquées dans des méthodes de plusieurs écrans de long. Courageux, Dave Lawper ne relâcha pas ses efforts, et ils finirent par payer. Il découvrit enfin l’erreur.

Après quelques secondes de réflexion, il comprit comment la corriger. Hélas, le temps passé à analyser s’amoncelait déjà bien trop, et Dave refuser d’arriver au prochain stand-up meeting sans apporter au moins une réussite, un bug corrigé, pour justifier son salaire.

Au fond de son âme, il savait qu’un refactoring s’imposait. L’architecture avait déjà été mise à mal par plusieurs évolutions hasardeuses de prédécesseurs depuis longtemps partis vers des horizons plus verdoyants. Mais la pression du résultat pesait sur ses épaules, et il finit par se résoudre à l’évidence. Ce n’était pas bien grave si, au lieu de remettre les choses à plat, il rajoutait un petit « if » crasseux pour corriger l’erreur. Après tout, il y en avait déjà quinze autres dans la méthode à la source du problème ! Alors un de plus ou un de moins, quelle différence ?

Bien heureux d’avoir enfin corrigé son problème, il s’empressa de livrer son correctif et rentra chez lui retrouver sa petite famille, l’esprit tranquille et soulagé. Mais au fond du fichier source, un mal bien plus grand rôdait, les yeux jaunes brillants dans la nuit, attendant patiemment l’exécution du code pour surgir…

Ne jetons donc pas la pierre à ce pauvre Dave. Cette histoire nous est arrivée à tous, que ce soit au début de notre carrière ou la semaine dernière. N’ayons donc pas honte de l’avouer, chacun de nous est passé par là au moins une fois dans sa vie.

Qui sommes-nous donc pour blâmer ce pauvre Dave Lawper ? Après tout, il connaissait mal ce code obscur écrit des années auparavant, et il n’a eu d’autre choix que de passer derrière d’autres de ses semblables qui n’ont pas forcément fait plus d’efforts que lui. Est-ce alors de la paresse de sa part, ou de la négligence ? Peut-être de la peur de refactorer un code tout entier sans en avoir la maîtrise, et la crainte de casser quelque chose qui pourrait ne pas être bien couvert par les tests ?

Comment notre pauvre Dave Lawper aurait pu éviter cette catastrophe ?

Une bonne réponse pourrait être la revue de code.

La revue de code, qu’est-ce que c’est ?

Pour faire court, la revue de code est la validation d’un code par un autre développeur. La définition est certes courte, mais elle cumule toute une liste d’avantages que la série d’articles à suivre essaiera d’énumérer.

Je veux lire la suite !

Sommaire

Gagnez en qualité

Eliminez les mauvaises pratiques

Soyez généreux, partagez

Resoudez votre équipe et gagnez en cohésion

Investissez sur l’avenir

Bilan et FAQ