Résumé
La sacro-sainte revue de code est-elle en danger ? Comment peut-on remettre en question
une pratique qui associée à la Pull (ou Merge) Request mise en évidence par les projets
Open Source et adoptée par toute une industrie, pourtant contradictoire avec un certain
nombre de pratiques héritées d'eXtreme Programming ?
Selon un expert (controversé), tout changement révolutionnaire passe par 3 étapes :
ridicule, dangereux, évident.
Confronté à notre industrie, nous pourrions représenter la revue de code et ses
alternatives à travers tout ou partie des 5 étapes d'adoption reconnues comme
Innovators, Early Adopters, Early Majority, Late Majority, et Lagards
Depuis de nombreuses années, les orateurs couvrant sur la revue de code (moi le premier)
se concentrent majoritairement sur la dimension humaine et l'outillage complémentaire à
Git. Il est temps de s'intéresser non pas spécifiquement aux outils, mais aux raisons
qui nous poussent à revoir les workflows de développement dans lesquels la revue de code
prend ses racines.
Dans ce talk, nous ne nous attarderons pas sur les pratiques de pair-programming ou le
mob-programming déjà bien connues, mais chercherons à nous convaincre des bénéfices de
zapper ou à minima alléger la revue de code. Après avoir posé le cadre, je vous
introduirai la philosophie Ship / Show / Ask puis expliciterai les pratiques que vous
pouvez mettre en place, non pas en alternative globale à la revue de code mais en
complément ou parfois remplacement sans en perdre les bénéfices.
Serez-vous les laggards de l'abandon de la revue de code systématique ?
