Dans les deux précédentes parties de notre série, nous avons parlé des premiers pas dans le métier de développeur et de ce qu'il vaut vraiment la peine d'apprendre au début de sa carrière.
Nous arrivons maintenant au moment que presque tout Junior redoute.
Le premier Code Review. Les premiers commentaires sur le code. Les premières corrections.
Et la première pensée : "Ai-je vraiment écrit ce code aussi mal ?"
Calmez-vous.
Nous sommes tous passés par là un jour.
Le Code Review n'est pas un examen
C'est probablement le plus grand malentendu parmi les développeurs débutants.
Beaucoup de Juniors prennent les commentaires sur leur code très personnellement. Le stress apparaît. L'incertitude. Parfois même la frustration.
Pourtant le but du Code Review n'est pas de prouver à quelqu'un qu'il a commis une erreur. Au contraire. C'est l'un des éléments les plus importants du processus de création d'un bon logiciel.
Grâce au Code Review :
- nous réduisons le risque d'erreurs,
- nous améliorons la lisibilité du code,
- nous apprenons les uns des autres,
- nous veillons à la cohérence du projet,
- nous transmettons le savoir entre les membres de l'équipe.
Les meilleures équipes ne considèrent pas le Code Review comme un contrôle. Elles le voient comme un échange quotidien d'expériences.
"Tu as 37 commentaires"
Ça fait peur ? Au début oui.
Un premier Pull Request ressemble souvent à ceci :
- Commentaire.
- Correction.
- Encore un commentaire.
- Nouvelle correction.
Après une heure on a l'impression que tout le code mérite d'être jeté. C'est normal.
Souvenez-vous d'une chose seulement. Le senior ne corrige pas le code pour montrer sa supériorité. Il le fait parce que dans quelques mois vous écrirez un code bien meilleur.
Et c'est exactement le but.
Un bon Senior ne dit pas seulement "c'est mauvais"
Les meilleurs développeurs avec qui nous avons travaillé expliquaient toujours :
- pourquoi il vaut mieux faire les choses différemment,
- quelles seront les conséquences de la solution actuelle,
- quelles alternatives existent,
- quelle solution sera plus facile à maintenir dans un an ou deux.
C'est une énorme différence.
On peut dire : "C'est mauvais."
Ou on peut dire : "Ça fonctionne, mais si dans six mois nous devons développer ce module, il sera bien plus facile à maintenir dans cette structure."
Dans le second cas, vous apprenez quelque chose de bien plus précieux que la simple correction. Vous apprenez une manière de penser.
Clean Code ne signifie pas du beau code
C'est un autre concept souvent mal compris.
Clean Code ne signifie pas un code qui a l'air spectaculaire. Il ne s'agit pas du nombre de lignes vides. Il ne s'agit pas de la longueur des fonctions. Il ne s'agit même pas de patterns spécifiques.
Il s'agit de quelque chose de bien plus simple : le code doit être lisible.
Si dans six mois vous ouvrez votre projet et que vous ne vous souvenez plus de ce que vous aviez en tête...
...alors probablement le code n'était pas suffisamment lisible.
Il y a un dicton : Nous écrivons du code pour des humains. Le compilateur ne vérifie que la syntaxe.
Et il y a beaucoup de vérité là-dedans.
Ne vous entichez pas de votre propre code
C'est l'une des leçons les plus importantes.
Le code n'est pas une œuvre d'art. Ce n'est pas un tableau. Ce n'est pas une sculpture.
C'est un outil pour résoudre un problème concret.
Si quelqu'un propose une meilleure solution...
...ça vaut la peine d'en discuter.
Pas parce que la personne a plus d'autorité, mais parce que peut‑être elle a vraiment une meilleure idée.
Ceux qui apprennent le plus sont les développeurs capables de dire : "Tu as raison. Faisons-le différemment."
"Chez moi ça marche"
Bon. Nous devions en venir à cette célèbre phrase. Chaque société a sa version de ce gag...
Imaginez la situation.
Le testeur signale un bug.
Le développeur répond : "Chez moi ça marche."
Le testeur vérifie une seconde fois. - Ça ne marche pas.
Le chef de projet regarde. - Ça ne marche pas.
Le client vérifie aussi. - Ça ne marche pas.
Mais... chez l'auteur du code, ça marche toujours.
Ça vous semble familier ?
La plupart du temps le problème ne réside pas dans le code lui‑même.
Les causes peuvent être très nombreuses :
- une autre version des données,
- un autre environnement,
- le cache,
- la configuration,
- les permissions,
- le navigateur,
- le système d'exploitation,
- un cas que personne n'avait prévu auparavant.
C'est pourquoi un développeur professionnel ne s'arrête pas à la phrase : "Chez moi ça marche."
Il pose la question suivante.
Pourquoi chez moi ça marche, et ailleurs non ?
C'est alors que commence le vrai débogage.
"C'est juste un petit changement"
Voici une autre phrase qui arrache un sourire dans la plupart des sociétés.
Le client dit : "C'est juste une petite correction."
Le développeur sait déjà qu'il va ouvrir un fichier que personne n'a touché depuis six ans.
Et ce "petit changement" s'avérera être une modification dans cinq modules, trois intégrations et deux bases de données.
C'est pourquoi les développeurs expérimentés prennent très au sérieux le mot "juste".
Les expressions les plus connues du secteur
Chaque profession a ses expressions. Les développeurs aussi.
Voici quelques-unes que presque tout le monde connaît :
- "Chez moi ça marche."
- "Cinq minutes."
- "Ce n'est pas un bug. C'est une fonctionnalité."
- "Mais je n'ai rien changé."
- "En production ça a planté."
- "Encore un seul déploiement."
- "C'est sûrement le cache."
- "Une petite correction rapide avant le week-end."
- "Ça devrait marcher."
Et probablement la plus dangereuse : "On le pousse en production le vendredi après 16h."
Si vous travaillez en IT...
...vous avez sans doute souri en lisant ceci.
Le développeur ne travaille pas seul
C'est un sujet souvent oublié. En réalité, la majorité des projets sont un travail d'équipe.
Le développeur collabore avec :
- les UX Designers,
- les UI Designers,
- les chefs de projet,
- les testeurs,
- les DevOps,
- les administrateurs,
- les analystes,
- les clients.
C'est pourquoi aussi importantes que soient les compétences techniques, il y a :
- la communication,
- la capacité d'écoute,
- le partage de connaissances,
- la responsabilité,
- le respect mutuel.
Le meilleur code ne sauvera pas un projet si l'équipe n'est pas capable de collaborer.
Glossaire
Code Review
Processus de revue du code par d'autres développeurs avant son déploiement. Il vise à améliorer la qualité du code, à détecter les erreurs et à partager les connaissances.
Pull Request (PR)
Proposition d'introduction de changements dans le projet. C'est généralement à ce stade que se déroule le Code Review.
Clean Code
Approche d'écriture du code dont l'objectif principal est la lisibilité, la simplicité et la facilité de maintenance, et non le nombre de patterns design utilisés.
Débogage (Debugging)
Processus de localisation et de suppression des causes d'erreurs dans une application.
Cache
Mécanisme stockant temporairement des données afin d'accélérer l'application. Il est souvent à l'origine de nombreux problèmes énigmatiques lors des tests.
Résumé
Plus nous travaillons comme développeurs, plus nous arrivons à une conclusion : les meilleurs développeurs ne sont pas ceux qui font le moins d'erreurs.
Les meilleurs développeurs savent :
- trouver plus rapidement la cause d'un problème,
- tirer des leçons,
- apprendre des autres,
- accepter la critique constructive,
- développer continuellement leur savoir-faire.
Le Code Review n'est donc pas un obstacle. C'est l'une des leçons les plus précieuses que l'on puisse recevoir au début de sa carrière.
Dans la dernière partie de notre série, nous parlerons du chemin du Junior au Senior. Nous expliquerons pourquoi un Senior Developer n'est pas quelqu'un qui a dix ans d'expérience, mais quelqu'un qui sait prendre la responsabilité d'un projet, penser en termes business et aider les autres membres de l'équipe à évoluer.
