La revue de code 2.0

Depuis l'époque des revues de code ponctuelles avec retours partagés en réunion ou dans un tableau excel les usages ont bien changé: revues systématiques du code sans échanges en face à face avec le développeur (via les merge requests, pull requests ou requête de tirage). Ces nouveaux usages ont des avantages mais aussi des inconvénients et sont souvent mal utilisés, mal vécus voire générateurs de conflits. En apprenant de ces erreurs, peut-on réinventer la revue de code et passer à la version 3.0 ?

Transcript

1. View Slide

2. Sandrine Banas
   @Cosjava
   20 ans
   

   View Slide

3. View Slide

4. View Slide

5. View Slide

6. View Slide

7. View Slide

8. La revue de code
   

   View Slide

9. View Slide

10. Lisibilité du code
    Améliorations
    syntaxiques
    Oubli d’implémentation
    Bug, défaut de conception
    Communiquer son état
    d’avancement
    Transfert de connaissances
    Accompagnement d’un junior
    Responsabilité collective du code
    

    View Slide

11. Les alertes
    

    View Slide

12. Les MR bloquent
    plus de 24h
    

    View Slide

13. Les MR bloquent plus de 24h
    Mettre les MR en visibilité
    Temps d’attente d’une pull/merge
    request pour être relue
    

    View Slide

14. View Slide

15. Certaines MR
    ne sont pas relues
    

    View Slide

16. Certaines MR ne sont pas relues
    Plus d’attractivité
    Mise en confiance des juniors
    Temps selon langage / taille des
    MR
    

    View Slide

17. La même personne
    lit toutes les MR
    

    View Slide

18. La même personne lit toutes les MR
    Rappel des règles
    Nombre de MR par relecteur
    

    View Slide

19. Auto-merge
    

    View Slide

20. View Slide

21. Copinage
    

    View Slide

22. Auto-merge / copinage
    Rappel des règles
    Développeur vs relecteur
    

    View Slide

23. Des échanges
    sans fin sur une MR
    

    View Slide

24. Des échanges sans fin sur une MR
    Règle sur la validation et
    échange de vive voix
    Nombre de MR dépassant un nv
    usuel de discussions
    

    View Slide

25. Les modifications
    en douce post-MR
    

    View Slide

26. Des MR
    temporairement
    fermées
    

    View Slide

27. Les modifications en douce post-MR
    Respect et bienveillance
    Des MR temporairement fermées
    

    View Slide

28. Des réactions
    émotionnelles
    attaque / fuite / repli sur soi
    

    View Slide

29. Des réactions émotionnelles
    Communication non violente
    

    View Slide

30. Les problèmes de fusion
    

    View Slide

31. View Slide

32. La partie cachée
    d’une
    Revue de code
    

    View Slide

33. View Slide

34. View Slide

35. La critique est aisée,
    et l’art est difficile.
    Philippe Néricault
    

    View Slide

36. Egoless programming
    Que peut-on faire à propos
    du problème de l’ego dans la
    programmation ?
    

    View Slide

37. Traiter les gens qui en savent
    moins que vous avec
    respect, déférence
    et patience
    

    View Slide

38. Comprendre et accepter
    que vous ferez des
    erreurs
    

    View Slide

39. Critiquer le code plutôt que
    les personnes.
    Soyez bienveillant
    pour le codeur pas pour le
    code.
    

    View Slide

40. Vous n’êtes pas
    votre code.
    

    View Slide

41. La programmation est une compétence
    comme les autres. Elle s’améliore avec la
    pratique. Si un pair vous montrait des
    façons d’améliorer votre jonglage, le
    prendriez-vous pour une attaque de votre
    caractère et de votre valeur en tant qu’être
    humain ?
    Debugging Teams, Better Productivity through Collaboration
    Brian W. Fitzpatrick, Ben Collins-Sussman
    

    View Slide

42. De la même manière, votre valeur
    personnelle ne devrait pas être liée au
    code que vous écrivez, ni à aucun projet
    créatif que vous construisez. Pour nous
    répéter: vous n'êtes pas votre code. Dites-le
    encore et encore. Vous n'êtes pas ce que
    vous faites.
    Debugging Teams, Better Productivity through Collaboration
    Brian W. Fitzpatrick, Ben Collins-Sussman
    

    View Slide

43. Bonnes
    pratiques
    Pour le codeur
    

    View Slide

44. Etat d’esprit
    Résilience et Gratitude
    Entretenir le désir d’apprendre
    Développement vs fixe (Carol Dweck)
    Kaizen
    

    View Slide

45. View Slide

46. View Slide

47. La responsabilité collective
    du code a de toute façon tendance à
    éviter que du code compliqué soit
    ajouté au système.
    Kent Beck (XP)
    

    View Slide

48. Si vous savez que qu'un aura très bientôt
    (dans quelques heures) l'occasion de lire le
    code que vous êtes en train d'écrire en ce
    moment, vous y réfléchissez à
    deux fois avant de créer de la complexité
    que vous n'êtes pas en mesure de justifier.
    Kent Beck (XP)
    

    View Slide

49. Petite
    250 lignes
    

    View Slide

50. Single
    Responsability
    Principle
    1
    

    View Slide

51. Titre clair
    Etiquettes
    

    View Slide

52. Formatage
    

    View Slide

53. Bonnes
    pratiques
    Pour le
    relecteur
    

    View Slide

54. Etat d’esprit
    Cultiver l’empathie, la gratitude
    et la curiosité
    

    View Slide

55. Bienveillance et
    Respect
    

    View Slide

56. cadre et
    checklist
    

    View Slide

57. Formulation
    

    View Slide

58. Retours positifs
    

    View Slide

59. 1 ou 2
    relecteurs
    

    View Slide

60. Utile?
     Lisibilité du code
     Qualité/maintenabilité
     Communication / transfert de comp.
     Responsabilité collective du code
     Uniformiser le code
     Importance de la lisibilité pour le client ?
     Qualité/maintenabilité peut être assurée par
    un outillage automatique
     Coût en temps
     Stress/tensions de la revue systématique
     Craftmanship
    

    View Slide

61. Sprint 0
    

    View Slide

62. La qualité avant l’humain
     Ressenti comme manque de confiance
     Stress de l’imposé
     Apprentissage forcé
     Le bien-être de l’équipe en premier lieu
    Valoriser les experts
     Soutenir les juniors
     Volontariat / confiance
     Des revues de code de vive-voix
     Revues automatisées
     Walkthrough review
    

    View Slide