Les révisions de code analphabètes ralentissent sérieusement le flux de travail. Lorsqu'un grand nombre de modifications sont bloquées pendant quelques jours (ou semaines!), Le produit devra alors être mis sur le marché. Voici quelques raisons pour lesquelles cela se produit:

Il n'y a pas de conception de code standard
Aucun contrôle automatisé utilisé
Les programmeurs n'analysent pas indépendamment leur code.
Énormes demandes de piscine
Vague Pool Requests
Délais manquants pour l'examen du code

Il n'y a pas de conception de code standard

Chaque équipe doit adopter une norme de format de code (norme de programmation, guide de style), avec laquelle tout le monde est d'accord. Cela inclut les conventions de dénomination, la structure des dossiers, la mise en forme du code et une liste des meilleures pratiques, telles que les tests unitaires, la validation, etc.

L'absence d'une norme et de conventions claires oblige chaque développeur à écrire du code comme il l'entend, ce qui entraîne des conflits de code. -la revue. Si vous voyez beaucoup de commentaires sur la mise en forme, les conventions de dénomination, etc., il est temps de parler d'une norme commune.

Votre équipe peut soit développer son propre ensemble de recommandations, soit commencer par des recommandations bien connues d'autres sociétés. Voici un exemple de Google .

Aucun contrôle automatisé utilisé

Après avoir adopté les normes de code, découvrez les outils pour vérifier la conformité avec ces normes. Pour presque toutes les langues, il existe des outils de formatage de code, de linters et d'autres utilitaires que vous pouvez mettre en place avant de valider et d'enregistrer dans les systèmes CI / CD.

Ces outils vérifient la conformité du code aux normes de conception et notifient l'auteur des violations. L'auteur a la possibilité de résoudre les problèmes avant d'envoyer une demande de pool, ce qui réduit considérablement le bruit. Plus il y a de contrôles qui passent automatiquement, plus le réviseur a de temps pour se concentrer sur des problèmes plus graves, tels que des failles dans l'architecture, des lacunes de mise en œuvre, etc.

Les programmeurs n'analysent pas indépendamment leur code.

Avant de contacter des collègues pour une révision du code, l'auteur doit revoir ses propres modifications. C'est comme vérifier le texte d'une lettre pour les fautes de frappe et les erreurs avant de l'envoyer au destinataire.

En pratique, la validation de votre propre code est difficile car vous avez tendance à ignorer inconsciemment les failles. Voici quelques façons d'améliorer la qualité de l'auto-analyse:

Faites une demande de pool sans nommer de réviseurs et revenez-y après quelques heures pour revoir vos modifications.
Supprimez votre tendance naturelle à inverser les changements et regardez-les intentionnellement ligne par ligne.
Suivez la liste de contrôle: le code est-il conforme à la norme de conception? Toutes les exigences commerciales sont-elles remplies? existe-t-il des tests pour tous les cas d'utilisation possibles? etc.

Énormes demandes de piscine

Le nombre de commentaires sur la demande de pool est inversement proportionnel au nombre de modifications qu'il contient. Autrement dit, un grand PR → quelques commentaires, un petit PR → beaucoup de commentaires.

Le fait est que les examinateurs n'étudient pas attentivement la demande de grande réserve, mais ont plutôt tendance à la parcourir afin de terminer le travail plus rapidement. Cela va à l'encontre de l'objectif d'une révision de code. Parfois, le contraire se produit lorsque l'auteur ne reçoit aucun commentaire pendant plusieurs jours, car le critique a peur de commencer à réviser trop de relations publiques.

Divisez la demande de pool en morceaux plus petits qui ont du sens séparément les uns des autres. Vous aiderez donc à les considérer correctement et rapidement.

Vague Pool Requests

On vous propose souvent une demande de pool avec une description vague ou sans elle. Le réviseur doit comprendre la signification des changements, en essayant de rappeler la tâche qui a été discutée quelque part dans la réunion ou dans le traqueur de bogues. Par conséquent, il est préférable de fournir au PR des informations complémentaires:

Quels changements contient-il
Avec quels fichiers commencer
Lien vers la tâche dans le traqueur de bogues
Captures d'écran si c'est une sorte de changement visuel

Ces informations fourniront un meilleur contexte pour le réviseur et accéléreront ainsi la révision du code.

Délais manquants pour l'examen du code

Une façon d'étirer la révision du code pour toujours est de ne pas fixer de délais pour le réviseur. Définissez des délais raisonnables, par exemple:

Le code de révision doit être rempli dans les 48 heures suivant l'envoi de la demande de pool.
Pour les correctifs, la période est de 30 minutes.

Merci d'avoir lu! :)

Comment accélérer la révision du code