Au cours de nombreuses années d'écriture et de révision de code, j'ai appris quelques secrets pour créer de meilleures demandes d'extraction et réviser le code plus efficacement.
J'ai dévoilé tous ces secrets dans mon nouveau livre Pull Requests and Code Review , mais vous trouverez ici un aperçu de ces 13 astuces, que vous pouvez déjà utiliser dans votre activité de développeur.
Pouvez-vous penser à d’autres conseils ? Partagez-les en commentaires 😉
Un brouillon de relations publiques vous aide à organiser vos idées et à documenter vos progrès, pendant que vous travaillez encore sur votre fonctionnalité.
La meilleure façon d’obtenir un examen rapide et efficace est de garder votre PR petit et bien documenté (avec tout le contexte nécessaire). Vous augmenterez également vos chances d'obtenir de futurs PR en fournissant un excellent code dès maintenant !
Retrouvez tous ces conseils et bien plus encore, avec davantage d'exemples concrets et d'informations exploitables dans mon livre gratuit Pull Requests and Code Review: Best Practices for Developers, from Junior to Team Lead .
Mettez-vous à la place de votre évaluateur, anticipez les questions et commentez votre propre code lorsque vous pensez que cela peut l'aider.
N'attribuez pas vos relations publiques au monde entier. Choisissez soigneusement vos évaluateurs pour obtenir un avis pertinent, sans attendre trop longtemps l'approbation.
Soyez ouvert aux commentaires, demandez des éclaircissements, dites lorsque vous n'êtes pas d'accord (avec respect) et répondez toujours aux commentaires.
Tout le monde a de nombreux PR à réviser et peu de temps libre. Si vous examinez d'autres PR, vous augmentez également vos chances de faire examiner le vôtre.
En tant que développeur junior, vous pouvez faire savoir aux autres lorsque vous ne comprenez pas une partie du code, car il devrait être compréhensible par n'importe quel développeur de l'équipe.
Plus d'informations à ce sujet dans mon article Comment réviser le code en tant que développeur junior ? .
L'objectif de la révision du code est de vérifier les bogues et les cas extrêmes, et de remettre en question la mise en œuvre. Il ne doit pas être utilisé pour pinailler sur des préférences mineures de formatage ou de style, ni pour des discussions architecturales à grande échelle.
Utilisez « pourquoi pas » au lieu de « vous devriez », soyez ouvert et positif et suggérez toujours une alternative lorsque vous demandez un changement.
Tous les commentaires ne nécessitent pas de modification, et toutes les modifications demandées ne sont pas nécessaires pour que le PR soit approuvé. Soyez clair dans votre commentaire si le changement n'est pas urgent.
Avant de rendre votre avis public, relisez chaque commentaire : vérifiez le ton que vous utilisez et assurez-vous de fournir tout le contexte pour aider la personne qui soumet le PR.
Vous ne voulez pas que le réviseur attende votre approbation deux jours après avoir apporté toutes les modifications que vous avez demandées. Lorsque vous l'examinerez, supposez que vous l'approuverez dès que tous les correctifs seront apportés.
Lorsqu'un fil de commentaires devient un débat dans vos relations publiques, vous feriez mieux de le couper et de suggérer de poursuivre la discussion ailleurs, par exemple dans un fil de discussion Slack. Si nécessaire, consacrez-y une réunion et/ou faites intervenir un tiers.
C'est ça! Qu'avez-vous pensé de ces conseils ? Pouvez-vous penser à un conseil que vous aimeriez donner aux autres développeurs ?
Partagez-les ici en commentaires 👇
Si vous avez aimé ces conseils et souhaitez en savoir plus, consultez mon livre Pull Requests and Code Review , c'est gratuit !
Également publié ici .