Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Merge requests de l'enfer au paradis

Merge requests de l'enfer au paradis

E0c9f21b6abfb645c2ab31445a3cf2a9?s=128

Sandrine Banas

November 12, 2019
Tweet

Transcript

  1. Merge request de l’enfer au paradis SANDRINE BANAS @COSJAVA

  2. None
  3. None
  4. None
  5. None
  6. None
  7. La merge request et l’agilité

  8. Les individus et leurs interactions plus que les processus et

    les outils La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
  9. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques

    semaines à quelques mois et une préférence pour les plus courts.
  10. Une attention continue à l'excellence technique et à une bonne

    conception renforce l’Agilité.
  11. La simplicité – c’est-à-dire l’art de minimiser la quantité de

    travail inutile – est essentielle.
  12. Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et

    le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  13. La revue de code

  14. Le feedback de la MR

  15. Lisibilité du code Améliorations syntaxiques Parfois détection d’un oubli d’implémentation

    -Rarement détection d’un bug, défaut de conception
  16. Communiquer son état d’avancement Transfert de connaissances Accompagnement d’un junior

    Responsabilité collective du code
  17. Les alertes sur la route de l’enfer

  18. Les MR bloquent plus de 24h

  19. Certaines MR ne sont pas relues

  20. La même personne lit toutes les MR

  21. Des échanges sans fin sur une MR

  22. Les modifications en douce post-MR

  23. Des MR temporairement fermées

  24. Les problèmes de fusion

  25. None
  26. La partie cachée d’une

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

  29. Que peut-on faire à propos du problème de l’ego dans

    la programmation ?
  30. Comprendre et accepter que vous ferez des erreurs 1.

  31. Vous n’êtes pas votre code. 2.

  32. 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
  33. 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
  34. Peu importe combien de « karaté » vous connaissez, quelqu’un

    d’autre en connaitra toujours plus. 3.
  35. Ne pas réécrire le code sans consultation 4.

  36. Traiter les gens qui en savent moins que vous avec

    respect, déférence et patience 5.
  37. La seule constante dans le monde est le changement. 6.

  38. La seule vraie autorité vient du savoir, pas de la

    position. 7.
  39. Battez-vous pour ce en quoi vous croyez, mais acceptez gracieusement

    la défaite 8.
  40. Ne soyez pas « le gars dans la pièce »

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

    le codeur pas pour le code. 10.
  42. None
  43. Petite 250 lignes

  44. Single Responsability Principle 1

  45. Titre clair Etiquettes

  46. Formatage

  47. None
  48. La responsabilité collective du code a de toute façon tendance

    à éviter que du code compliqué soit ajouté au système. Kent Beck (XP)
  49. 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)
  50. Bienveillance et Respect

  51. cadre et checklist

  52. Formulation

  53. 1 ou 2 relecteurs

  54. 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
  55. Sprint 0