Revues de code efficaces

Les revues de code sont une partie essentielle de toute équipe de développement de logiciels, elles vous aident à réduire les risques d'avoir du code bogué.

Moi-même, je fais des révisions de code depuis plus de 6 ans maintenant et pendant cette période, j'ai passé en revue plus de 600 requêtes Pull. J'écris maintenant cet article pour partager mes apprentissages, dans l'espoir qu'il aidera à la fois l'examinateur et l'évalué.

Avant de nous plonger dans le terrier du lapin de ce qu'il faut faire et ne pas faire pendant les revues de code, je tiens à souligner l'importance des revues de code.

Les gens pensent généralement que les révisions de code sont une tâche subalterne qui ne fait qu'augmenter le temps entre "Dev Done" et "Ready for QA". La déclaration susmentionnée est « vraie » lorsque les révisions du Code sont effectuées « Pas avec les bonnes intentions ».

Voici quelques scénarios qui s'agrègent à la révision du code en cours mais n'aident personne -

1. Le réviseur fait la révision du code juste pour le plaisir de le faire. Il approuve les demandes sans regarder ou ne les fait défiler qu'une seule fois.
   Ces types de réviseurs sont rapidement qualifiés de réviseurs faciles et sont ensuite ciblés pour faire passer le code plus rapidement.
2. Le réviseur effectue la révision du code sans comprendre les exigences de la tâche
3. L'examinateur ajoute des commentaires sans le raisonnement réel derrière pourquoi le changement est nécessaire
4. Le réviseur ne vérifie que la syntaxe et non la logique réelle.
   Si un examinateur pense que l'évalué en sait plus que lui, c'est inévitable.
5. L'évalué n'essaie pas de comprendre le raisonnement derrière un commentaire. Donc, soit il suit aveuglément les commentaires, soit il les ignore

Pourquoi devrais-je revoir le code de quelqu'un d'autre ?
On pourrait penser qu'il n'y a aucun avantage à revoir le code d'une autre personne car elle pourrait croire qu'elle n'apprend rien de nouveau. Au contraire-

1. Les réviseurs comprennent les tâches qui se déroulent au sein de l'équipe.
2. Ils apprennent à connaître les services qui existent au sein du système. Ce qui améliore la réutilisabilité
3. Ils apprennent de nouvelles syntaxes ou façons de coder et de faire les choses

Cependant, j'énumérerais toujours certaines choses que les gens manquent généralement lors de la révision du code.

Conditions générales d'Utilisation

1. Une attention particulière doit être accordée à la « lisibilité du code » et à la « réutilisabilité du code »
   Les noms de variable et de fonction sont descriptifs et significatifs. Les noms comme i, ane doivent pas être utilisés.
2. Le code ne doit pas être redondant (les outils de qualité de code comme "sonarlint" sont très utiles dans ces cas)
3. Les cas de tests unitaires sont indispensables pour les fonctions utilitaires
4. Chaque travail de fonction doit être clairement défini et doit suivre le principe de responsabilité unique
5. Vérifiez les niveaux de journalisation. Le contenu du journal doit contenir des informations exploitables
   Quelque chose comme — « erreur du cache » ne contient aucune information exploitable
6. Nous devrions avoir des métriques en place partout où cela est nécessaire
7. Vérifiez si le processus (journalisation, appels externes, base de données, cache) doit être synchronisé ou asynchrone
8. Les gens ne prêtent généralement pas beaucoup d'attention aux cas de test unitaire. Il convient de réfléchir à la question de savoir si tous les scénarios sont couverts ou non
9. Pour une fonctionnalité cruciale qui pourrait avoir un impact sur le parcours de l'utilisateur, il faut toujours avoir une solution de repli pour revenir au flux précédent
10. L'évalué doit essayer de diviser les modifications en plusieurs composants plus petits et de créer des demandes d'extraction pour eux indépendamment et le plus tôt possible. Cela donne non seulement plus de temps à l'examinateur, mais garantit également que les problèmes (le cas échéant) ou les scénarios de bord sont détectés tôt
11. Ne fais confiance a personne. Tout remettre en question. Parfois, si nous faisons confiance à l'auteur, nous ne creusons pas profondément dans son code.
12. L'évalué doit relire sa pull request au moins une fois avant de la partager pour examen. Cela garantit que les éléments de base tels que le code commenté, les TODO en attente, les modifications des espaces blancs, etc. sont corrigés avant même de partager le PR
13. Vérifiez les branches source et destination, si elles sont correctes ou non.

1. Si l'appel externe est fortement couplé ou non (hautement couplé signifie - une erreur dans l'appel externe entraînera une erreur dans ce flux)
2. Délais d'expiration et mécanismes de nouvelle tentative
3. Exigences en matière d'échantillonnage et de limitation du taux
4. Métriques pour les appels externes (latence, taux de réussite)

1. Vérifier la TTL par défaut et la logique d'actualisation du cache
2. Nous devrions également estimer le nombre de nouvelles entrées et le taux d'accès au cache lors de l'ajout d'un cache
3. Que se passe-t-il en cas d'erreur du cache
4. Dans le cas d'un nouveau cluster de cache — si la connectivité existe entre le serveur et l'instance de cache
5. Métriques pour le taux d'accès au cache
6. Une estimation du nombre de clés de cache, la taille moyenne de la valeur et la vérification qu'Infra a une capacité suffisante.

1. Vérifiez si un index correct est présent dans la base de données pour la nouvelle requête
2. Dans le cas d'une nouvelle base de données - que la connectivité existe ou non
3. Politique de purge des tables, pour éviter les tables volumineuses dans le temps, en cas d'insertions de données
4. Métriques pour les nouvelles requêtes

1. Supprimer les modifications d'espacement de la requête Pull
   Comment ? Vous pouvez vous référer à ceci
2. Si je ne suis pas au courant de l'exigence, je vérifie généralement la tâche ou me synchronise avec le développeur une fois pour comprendre l'exigence
3. Ouvrez simultanément la demande d'extraction sur GitHub/BitBucket et l'éditeur de code local.
   Avoir le code localement présente de multiples avantages -
   - Vous pouvez utiliser des outils d'analyse de code statique pour trouver certains des problèmes courants
   - La navigation dans le code est beaucoup plus facile
   - Si nécessaire, vous pouvez exécuter le code pour voir comment il se comporte
4. Commencez par le point où le flux commercial est impacté, puis parcourez le code à partir de là. Chaque fois que je passe à un autre fichier, vérifiez si ce fichier a changé ou non dans la requête Pull sur Github.
5. En cas de problème, ajoutez ce commentaire dans le GitHub tout en mentionnant ce qui doit être changé et pourquoi ? Avec quelques documents de référence
6. Au cas où vous auriez fini de réviser un fichier - marquez-le comme vu, de sorte que vous obteniez également des éclaircissements sur la progression de la révision et que vous puissiez également éviter le fichier lors de la deuxième révision du code (si aucun changement )
7. Si les changements dans le diff sont minimes, je le révise en une seule fois. Sinon, je divise l'examen en petites phases. Cela garantit que la qualité de l'examen n'est pas affectée. En général, ce qui se passe, c'est que si la différence est importante, après un certain point, nous commençons à accepter les changements sans trop y réfléchir.

J'espère qu'il y a au moins une chose que vous avez apprise de cela. Si oui, votez pour et mentionnez également les points que j'aurais pu manquer. Je les ajouterai également au post.

Bravo et bonne révision !