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 😉
1. Créez votre PR avant que le code ne soit prêt à être révisé
Un brouillon de relations publiques vous aide à organiser vos idées et à documenter vos progrès, pendant que vous travaillez encore sur votre fonctionnalité.
2. Donnez envie aux gens de revoir vos relations publiques
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 .
3. Soyez le premier évaluateur de votre PR
Mettez-vous à la place de votre évaluateur, anticipez les questions et commentez votre propre code lorsque vous pensez que cela peut l'aider.
4. Attribuez les bons évaluateurs à votre PR
N'attribuez pas vos relations publiques au monde entier. Choisissez soigneusement vos évaluateurs pour obtenir un avis pertinent, sans attendre trop longtemps l'approbation.
5. Soyez réactif aux commentaires
Soyez ouvert aux commentaires, demandez des éclaircissements, dites lorsque vous n'êtes pas d'accord (avec respect) et répondez toujours aux commentaires.
6. Si vous voulez que les gens examinent vos PR, vous devez consulter les leurs
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.
7. Vous pouvez réviser le code même si vous êtes un développeur junior
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 ? .
8. Vérifiez les bonnes choses lors de la révision du code
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.
9. Utilisez le bon ton dans vos commentaires
Utilisez « pourquoi pas » au lieu de « vous devriez », soyez ouvert et positif et suggérez toujours une alternative lorsque vous demandez un changement.
10. Expliquez clairement si un changement est nécessaire pour que vous puissiez approuver le PR ou non
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.
11. Vérifiez votre avis avant de le soumettre
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.
12. Approuvez le PR lorsque le demandeur a apporté toutes les modifications que vous avez demandées
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.
13. Certains conflits ne peuvent pas être résolus dans les commentaires
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 .
