Voici un deuxième article que je tire d’une traduction du livre 97 choses que tout programmeur devrait savoir.

Cet article, écrit par Mattias Karlsson, traitera du code review.

Voici cet article :

Vous devriez faire du Code Reviews. Pourquoi? Parce qu’ils augmentent la qualité et réduisent le taux de défauts. Mais pas nécessairement pour les raisons que vous pourriez penser.

Parce qu’ils avaient déjà eu de mauvaises expériences avec des critiques de code, de nombreux programmeurs ont tendance à ne pas les aimer. J’ai vu des organisations exigeant que tout le code passe un examen formel avant d’être déployé dans la production. Souvent, c’est l’architecte ou un développeur principal qui effectue cette revue, une pratique qui peut être décrite comme un examen complet de l’architecte. Ceci est indiqué dans le manuel de processus de développement de logiciels de l’entreprise, auquel tous les programmeurs doivent se conformer.

Il se peut que certaines organisations aient besoin d’un processus rigide et formel, mais la plupart ne le font pas. Dans la plupart des organisations, une telle approche est contre-productive. Les examinateurs peuvent avoir l’impression qu’ils sont jugés par une commission des libérations conditionnelles. Les examinateurs ont besoin à la fois du temps pour lire le code et le temps nécessaire pour se tenir au courant de tous les détails du système; ils peuvent rapidement devenir le goulet d’étranglement dans ce processus, et le processus peut dégénérer rapidement.

Au lieu de simplement corriger les erreurs dans le code, le but des Code Reviews devrait être de partager des connaissances et d’établir des lignes directrices communes sur le codage. Le partage de votre code avec d’autres programmeurs permet la propriété de code collectif. Laissez un membre aléatoire de l’équipe parcourir le code avec le reste de l’équipe. Au lieu de chercher des erreurs, vous devriez examiner le code en essayant de l’apprendre et de le comprendre.

Soyez doux lors des Code Reviews. Assurez-vous que les commentaires sont constructifs, pas caustiques. Introduire différents rôles pour la réunion d’évaluation afin d’éviter d’avoir une ancienneté organisationnelle parmi les membres de l’équipe affectant le Code Review. Des exemples de rôles pourraient inclure un focus sur la documentation, un autre sur les exceptions et un tiers pour examiner la fonctionnalité. Cette approche contribue à répartir le fardeau de la Review entre les membres de l’équipe.

Ayez une journée régulière de Code Reviews chaque semaine. Passez quelques heures dans une réunion de review. Faites pivoter la revue chaque réunion dans un pattern de round-robin. N’oubliez pas de changer également les rôles entre les membres de l’équipe. Impliquez des débutants dans des critiques de code. Ils peuvent être inexpérimentés, mais leur nouvelle connaissance universitaire peut donner une perspective différente. Inventez des experts pour leur expérience et leurs connaissances. Ils identifient le code sujet aux erreurs plus rapidement et avec plus de précision. Les code reviews vont plus facilement si l’équipe possède des conventions de codage vérifiées par des outils. De cette façon, le formatage du code ne sera jamais discuté lors de la réunion d’examen du code.

Faire des commentaires sur le code est peut-être le facteur le plus important pour le succès. Les commentaires portent sur la révision des personnes. Si la réunion d’examen est douloureuse ou ennuyeuse, il sera difficile de motiver quelqu’un. Faites-en une code review informel dont le but principal est de partager les connaissances entre les membres de l’équipe. Laissez les commentaires sarcastiques à l’extérieur et apportez un gâteau ou un déjeuner à café à la place.