Faire de la revue de code comme un "pro" - Cabane Québec 2019

La revue de code est un super outil pour attraper des erreurs, disséminer les idées et le savoir, et alimenter la collaboration entre les membres de votre équipe. Voyons ensemble le pourquoi et le comment de la revue de code, autant du côté dévelopeur que du côté business. Comment faire une requête de changement facile à réviser, quoi automatiser, à quels détails être le plus attentif et quels sont les gains pour votre entreprise.

Transcript

2. Mais... à quoi ça sert ?
3. Réduit les coûts
4. Stimule la collaboration ✦ permet de briser les silos ✦ favorise l'ownership du projet ✦ "coaching" de devs plus juniors
5. Améliore la communication ✦ diffusion de pratiques émergentes ✦ règle de l'autobus ! ✦ conserve les discussions sur le code ✦ facilite le travail avec employés "remote"
6. Être un réviseur pro
7. Donnez du contexte
9. "corriger bug N+1"
11. Donnez des exemples
12. "Voici comment récupérer le count"
13. Dirigez vers de la documentation
14. Suggérez des changements
16. Critiquez le code, jamais la personne
17. Félicitez les bons coups > Good job, c'est génial comme système d'alertes !
18. Posez des questions
19. Répondez aux questions
20. Préparez une "checklist" de points à valider
21. Checklist de réviseur
22. Tenez vos revues à < 200-400 loc
23. Tenez vos revues à < 60-90 min
24. Prenez au moins 5 min *même pour 1 seule ligne
25. Être un auteur pro
26. Ouvrez une PR/MR le plus tôt possible
27. Limitez la portée de vos changements
28. Revue de 5 lignes vs 5000 lignes
29. Faites des commits "logiques"
30. Racontez une histoire * 2eaf071 - revert fix * 75edd04 - fix bug * 561d6ff - *derp* * c803f9e - ajouter fichiers
31. Racontez une histoire * 2eaf071 - Stocker les pdfs générés dans le bucket 2 * 75edd04 - Stocker les images dans le bucket 1 * 561d6ff - Configuration des 2 buckets S3 * c803f9e - Installation du SDK d'AWS via composer
32. N'hésitez pas à donner du contexte
33. Gardez votre historique propre
34. Faites un "auto peer-review"
35. ! Annotez vos changements
36. Faites rouler les tests
37. ! Isolez les changements esthétiques
38. ! Automatisez les changements esthétiques
39. Gardez votre branche à jour
40. Gardez une "checklist" de vos erreurs courantes
41. Checklist d'auteur
42. Vous n'êtes pas votre code
43. Être une équipe pro
44. Établissez vos standards
45. Linting (SCSS/LESS/CSS, JS/ES, Python, etc)
46. Formattage automatique
47. Créez-vous des templates
48. Variez les réviseurs
49. Réservez du pour la revue de code
50. Assigner/choisir ses réviseurs
51. Les outils de pros
52. Développement collaboratif
53. Intégration continue (CI)
54. Synchronizez vos outils ensemble
55. Configurez le nombre de revues requises
56. TextExpander
57. Annotate
58. Bonne revue de code! Merci!
59. Questions ?