La revue de code 2.0

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 ?

E0c9f21b6abfb645c2ab31445a3cf2a9?s=128

Sandrine Banas

November 25, 2020
Tweet

Transcript

  1. None
  2. Sandrine Banas @Cosjava 20 ans

  3. None
  4. None
  5. None
  6. None
  7. None
  8. La revue de code

  9. None
  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
  11. Les alertes

  12. Les MR bloquent plus de 24h

  13. Les MR bloquent plus de 24h Mettre les MR en

    visibilité Temps d’attente d’une pull/merge request pour être relue
  14. None
  15. Certaines MR ne sont pas relues

  16. Certaines MR ne sont pas relues Plus d’attractivité Mise en

    confiance des juniors Temps selon langage / taille des MR
  17. La même personne lit toutes les MR

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

    Nombre de MR par relecteur
  19. Auto-merge

  20. None
  21. Copinage

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

  23. Des échanges sans fin sur une MR

  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
  25. Les modifications en douce post-MR

  26. Des MR temporairement fermées

  27. Les modifications en douce post-MR Respect et bienveillance Des MR

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

  29. Des réactions émotionnelles Communication non violente

  30. Les problèmes de fusion

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

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

  36. Egoless programming Que peut-on faire à propos du problème de

    l’ego dans la programmation ?
  37. Traiter les gens qui en savent moins que vous avec

    respect, déférence et patience
  38. Comprendre et accepter que vous ferez des erreurs

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

    le codeur pas pour le code.
  40. Vous n’êtes pas votre code.

  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
  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
  43. Bonnes pratiques Pour le codeur

  44. Etat d’esprit Résilience et Gratitude Entretenir le désir d’apprendre Développement

    vs fixe (Carol Dweck) Kaizen
  45. None
  46. None
  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)
  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)
  49. Petite 250 lignes

  50. Single Responsability Principle 1

  51. Titre clair Etiquettes

  52. Formatage

  53. Bonnes pratiques Pour le relecteur

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

  55. Bienveillance et Respect

  56. cadre et checklist

  57. Formulation

  58. Retours positifs

  59. 1 ou 2 relecteurs

  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
  61. Sprint 0

  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