7 bonnes pratiques pour accélérer les revues de code

Les revues de code peuvent être pénibles. Les ingénieurs logiciels se plaignent souvent que le processus de révision est lent, retarde les tâches en aval et entraîne un changement de contexte lorsque vous naviguez entre une demande d'extraction (PR) ouverte et votre tâche suivante. Les révisions de code peuvent également être pleines de tatillons et de délestage de vélos, ce qui en fait une mauvaise expérience pour toutes les personnes impliquées.

Pour remédier à ce problème, certains ingénieurs sont même allés jusqu'à suggérer de supprimer complètement les demandes d'extraction et les revues de code. Bien que cela puisse fonctionner pour les petites équipes dans les startups, je ne pense pas que ce soit la bonne solution pour tout le monde, en particulier les entreprises au niveau de l'entreprise.

Au contraire, il existe de nombreuses façons de faire du processus de révision du code une meilleure expérience à la fois pour l'auteur du code et pour le réviseur du code. Examinons ensemble sept de ces meilleures pratiques.

#1 : Gardez les demandes d'extraction petites

Chaque ingénieur redoute d'examiner les demandes d'extraction qui ont plus de 1000 lignes de code modifiées. Ces révisions peuvent prendre des heures, et souvent, ce qui finit par arriver, c'est que l'examinateur commence à parcourir le code plutôt que de l'examiner attentivement.

La solution est de garder vos demandes d'extraction petites. Les petits PR sont plus faciles et plus rapides à examiner car l'examinateur n'a pas besoin de passer autant de temps à construire un modèle mental de la façon dont tous les changements fonctionnent ensemble. Il y a aussi moins de code modifié, ce qui, espérons-le, équivaut à moins d'erreurs, moins de commentaires et moins de va-et-vient entre l'auteur et le réviseur.

Garder vos PR petits peut sembler difficile au début, mais cela peut être fait si vous décomposez votre travail en petites tâches et restez concentré. Ne faites pas de refactorisations majeures tout en implémentant de nouvelles fonctionnalités ou en corrigeant des bogues. Utilisez des indicateurs de fonctionnalité dans votre code afin de pouvoir fusionner de petites parties de nouvelles fonctionnalités dans la branche principale sans qu'elles n'apparaissent dans l'application de production.

Gardez vos relations publiques petites. Vos examinateurs vous en seront reconnaissants.

#2 : Utiliser des modèles de demande d'extraction

Un autre désagrément est de se voir demander d'examiner une demande d'extraction sans aucun contexte. Lorsqu'un PR tombe sur vos genoux sans explication, vous vous demandez souvent : « À quoi sert ce PR ? Quel problème cela résout-il ? Y a-t-il une tâche connexe pour cela ? Pourquoi cette approche particulière a-t-elle été adoptée ? »

Un modèle de demande d'extraction est un petit formulaire configurable que vous pouvez définir comme texte par défaut sur chaque nouvelle demande d'extraction. Le modèle PR invite l'auteur du code à fournir des détails pertinents pour son PR. En règle générale, un modèle de relations publiques demanderait une brève description de ce que vous avez fait et pourquoi, un lien vers le ticket de tâche et un plan de test pour valider les modifications.

Les bons modèles de relations publiques incluent également généralement une courte liste de contrôle que l'auteur du code doit parcourir pour s'assurer qu'il n'a manqué aucune des bases. Cette liste de contrôle peut inclure des éléments tels que les tests unitaires, les documents, l'internationalisation, la prise en charge de plusieurs navigateurs et l'accessibilité.

Vous trouverez ci-dessous un exemple de modèle de demande d'extraction que j'aime utiliser pour tous mes dépôts :

#3 : Mettre en œuvre des SLA de temps de réponse

Si vous constatez que les demandes d'extraction restent non examinées plus longtemps que vous ne le souhaiteriez, c'est le bon moment pour définir les attentes en équipe quant à la rapidité avec laquelle une nouvelle demande d'extraction doit être examinée. En d'autres termes, quelle est la durée maximale pendant laquelle un PR peut exister avant qu'il ne doive être récupéré ? Une heure? Deux heures? 24 heures?

Votre réponse à cette question dépendra probablement de la taille de votre équipe. Vous pouvez également avoir une réponse différente pour les demandes d'extraction internes de votre équipe par rapport aux demandes d'extraction externes d'autres équipes.

Lors du choix d'un SLA (accord de niveau de service) de temps de réponse, vous souhaiterez trouver le bon équilibre. Il n'est pas raisonnable de s'attendre à ce que tout le monde abandonne immédiatement ce qu'il fait et révise votre code lorsque vous publiez un nouveau PR, mais vous ne voulez pas non plus que les PR restent sans révision pendant des heures.

Trouvez le bon équilibre qui permet à vos coéquipiers d'entrer dans un état de flux. Ils devraient être capables de travailler sur leur propre code, puis de revoir les PR à des points d'arrêt naturels tout au long de la journée.

Personnellement, j'aime avoir un SLA de temps de réponse de deux heures pour les RP internes et un SLA de 24 heures pour les RP externes.

Indépendamment de ce que vous et vos coéquipiers décidez, avoir un accord d'équipe vous permet de vous tenir mutuellement responsables. Si tout le monde s'est mis d'accord sur un SLA spécifique et que le temps s'est écoulé pour l'un de vos PR, vous savez que vous pouvez commencer à embêter les gens à ce sujet.

#4 : Former des ingénieurs juniors et intermédiaires

Les opportunités de formation sont partout. Le mentorat d'ingénieurs moins expérimentés ne se limite pas à leur enseigner les technologies et les langages avec lesquels ils travaillent. Cela inclut également de leur enseigner des compétences non techniques telles que la façon de faire une révision de code efficace.

Apprenez à vos coéquipiers ce que vous recherchez lors d'une revue de code. Aidez-les à comprendre ce qui est important et ce qui ne l'est pas. Apprenez-leur à communiquer efficacement dans leurs commentaires de revue de code , par exemple en préfixant les suggestions non bloquantes par « nit ».

Il existe de nombreuses ressources intéressantes sur la façon d'être un réviseur de code plus efficace. Le Code Review Developer Guide de Google vaut la peine d'être lu dans son intégralité. Le guide contient d'excellents conseils à la fois pour l'auteur du code et pour le réviseur du code. Pour une ressource plus effrontée, How to Make Your Code Reviewer Fall in Love with You est facilement l'un des meilleurs conseils (et divertissants) pour les développeurs qui créent des pull requests.

#5 : Configurer des pipelines d'intégration continue

Les révisions de code deviennent fastidieuses lorsque la plupart des commentaires sont des choses comme "Point-virgule manquant" ou "L'indentation semble fausse ici". Ne perdez pas de temps pendant les révisions de code sur des choses que les formateurs de code et les linters de code peuvent prendre en charge pour vous. Laissez les ordinateurs automatiser les choses triviales afin que vous puissiez vous concentrer sur les choses importantes qui nécessitent un humain.

Pour les projets JavaScript, il est simple de configurer un formateur comme Prettier et un linter comme ESLint pour votre référentiel. Vous pouvez ensuite configurer une intégration continue pour votre dépôt en utilisant quelque chose comme Travis CI , CircleCI , GitHub Actions ou GitLab CI/CD .

Votre pipeline CI exécutera ces tâches de formatage et de linting pour vous avec vos tests unitaires. Si le pipeline CI échoue à n'importe quelle étape d'une demande d'extraction, il empêchera la fusion de cette demande d'extraction.

Vous avez maintenant automatisé plusieurs parties importantes de la révision du code, ce qui vous fait gagner des heures.

#6 : Utiliser les applications d'examen des requêtes d'extraction

Parfois, il est nécessaire non seulement d'examiner le code dans une demande d'extraction, mais également d'afficher manuellement les modifications dans l'application pour vérifier que tout semble bon. Pour les applications avec des étapes de configuration complexes, extraire le code de quelqu'un d'autre et l'exécuter localement sur votre machine peut prendre de cinq minutes à une heure. Quel mal de tête !

Les applications d'examen des demandes d'extraction sont utilisées pour déployer automatiquement votre code dans un environnement de test de courte durée chaque fois qu'un nouveau PR est créé. Cela permet aux réviseurs d'inspecter facilement les modifications de l'interface utilisateur sans avoir à dérouler le code et à l'exécuter localement sur leur machine. Non seulement cela permet de gagner du temps, mais cela incite également les réviseurs à être plus approfondis dans leurs révisions en les simplifiant.

#7 : Générez des diagrammes pour visualiser vos changements de code

Lors de la révision du code dans GitHub ou GitLab, les fichiers sont généralement affichés par ordre alphabétique. Pour les PR relativement petits, cela peut ne pas être un problème. Mais lorsqu'il y a des dizaines de fichiers impliqués dans un PR, il est parfois utile de voir ces changements regroupés logiquement afin que vous puissiez voir comment ils s'intègrent dans une image plus grande.

Les cartes de révision CodeSee vous aident à visualiser quels fichiers ont été modifiés et comment ces modifications affectent leurs dépendances en amont et en aval. Ils s'intègrent à GitHub pour publier automatiquement un commentaire et un diagramme sur votre PR. Vous pouvez même créer des visites interactives de votre code pour guider vos réviseurs de code. Mieux encore, CodeSee Maps est gratuit pour les organisations open source et leurs référentiels publics.

Conclusion : 7 façons de réduire considérablement votre temps de révision de code

Pour récapituler, voici sept conseils pour réduire considérablement votre temps de révision de code :

1. Gardez les demandes d'extraction petites.
2. Utilisez des modèles de demande d'extraction pour fournir tout le contexte dont un réviseur aurait besoin.
3. Mettre en œuvre des SLA de temps de réponse.
4. Formez les ingénieurs juniors et intermédiaires sur les éléments clés que vous recherchez lors d'une revue de code.
5. Configurez des pipelines CI pour exécuter des linters, des formateurs et des tests unitaires.
6. Utilisez les applications d'examen des demandes d'extraction afin de pouvoir facilement inspecter les modifications de l'interface utilisateur.
7. Générez des diagrammes pour visualiser vos modifications de code à l'aide d'un outil tel que CodeSee Review Maps.

Merci d'avoir lu et bon codage !

Également publié ici