La transition d’un développeur vers un rôle de chef d’équipe peut être à la fois difficile et gratifiante.
Vous prenez des décisions à fort impact. Vous guidez et encadrez vos pairs. Vous cultivez des compétences de leadership.
Mais les développeurs qui accèdent pour la première fois à ces responsabilités commettent une erreur fréquente : ils essaient d’effectuer toutes les revues de code.
Ils craignent que s’ils ne le font pas, quelque chose se casse en production. Ou peut-être que la qualité du code se détériorera au fil du temps.
Il n’est pas possible de réviser toutes les demandes de retrait. Vous avez une bande passante limitée dans votre quotidien. De nombreux projets requièrent votre attention et votre priorité. Tout réviser n’est pas compatible avec votre temps.
Alors, que devriez-vous faire à la place ?
Voici 7 conseils pour permettre à votre équipe d’effectuer des revues de code de manière efficace.
1. Améliorez vos systèmes de diffusion en dehors de la revue de code
Renforcez vos pipelines de publication. Prévenir les défauts avec des tests robustes et fiables. Détectez les défauts grâce à la surveillance et à l’observabilité. Atténuez les défauts grâce à un retour en arrière automatique des changements ayant un impact négatif.
Ajoutez des vérifications automatisées pour les tests et l’approbation avant que les PRs puissent être fusionnés.
2. Documenter les attentes en matière de revue de code
Les membres de l’équipe doivent connaître la taille, la portée et la structure attendues pour chaque PR.
Détaillez les attentes des auteurs de RP, par exemple :
- Le contexte et les détails attendus pour chaque PR
- Quand procéder à un remaniement – dans un PR distinct ou dans le même PR ?
- Comment amener les désaccords à la résolution
Détaillez les attentes des réviseurs de RP, par exemple :
- Allez-y rapidement
- Soyez aimable – donnez une raison à chaque commentaire
- Privilégiez le pragmatisme, pas le perfectionnisme
3. Établir des paradigmes
Introduire des modèles de conception et une structure dans la base de code, que les autres peuvent exploiter et construire par-dessus.
Documentez les interfaces et les modules, et la manière dont ils interagissent. Les conceptions évoluent constamment – gardez cette documentation à jour.
4. Intégrer des outils automatisés
Utilisez des linters et des formateurs pour assurer un style cohérent. Idéalement, vos coéquipiers ne discuteraient pas du tout du style pendant les revues de code.
Mettez en place des outils automatisés d’analyse statique du code. Ils vous aideront à détecter les défauts évidents et à identifier les opportunités de meilleures pratiques.
5. Apprenez à votre équipe à réviser efficacement
Soulignez l’importance de la gentillesse, de la clarté et de la minutie.
Documentez quand le blocage est ou n’est pas justifié.
Exemples de cas où le blocage est justifié :
- Défauts
- Risques
- Ingénierie excessive
Exemples où le blocage n’est pas justifié – dans ces situations, commentez et approuvez :
- Style
- Points faibles
- Corrections urgentes
6. Soyez au courant de ce qui est expédié
Intégrez un canal Slack à GitHub, spécifiquement pour les événements et les commentaires des Pull Request. Parcourez ce canal toutes les heures environ.
Pour les changements à faible risque, laissez vos coéquipiers s’en occuper. Mais sachez quand il faut faire un examen approfondi et éviter de faire des folies.
7. Donnez à vos pairs un peu d’espace pour apprendre de leurs erreurs
Vous ne pouvez pas tout éviter. Les logiciels ne seront jamais parfaits, et des défauts occasionnels se glisseront.
Traitez ces événements comme des expériences d’apprentissage et des moments propices à l’apprentissage. Aidez vos pairs à se développer.
N’oubliez pas que vous ne pouvez pas écrire et réviser tout le code de votre équipe. Si vous le pouviez, il serait inutile d’engager d’autres personnes.
Au lieu de cela : mettez votre équipe en position d’expédier de meilleurs logiciels, plus rapidement. 🚢
