💡 La revue par les pairs a été maintes fois étudiée sous l’angle de la réduction des défauts. Qu’en est-il du partage du savoir ? Les auteurs ont étudié les pratiques de revue de code en vigueur dans l’Open Source, mais aussi chez Google, AMD et Microsoft. L’époque des process lourds est achevée, la majorité de la profession utilise désormais des méthodes de revue légères, moins formelles, voire laissant la part belle à la revue avant commit.
🤝 La revue de code d’est hybridée avec le Pair Programming, en devenant “une résolution de problèmes en groupe”, plutôt qu’une recherche méthodique de défauts. A ce titre, les auteurs notent que le nombre optimal de reviewers est de … deux. Cette vision de la review évite le context-switching que provoque le rejet simple de la modification.
🔦 Plus intéressant, les auteurs notent que les développeurs ne se limitent pas aux fichiers sur lesquels ils ont déjà travaillé lors d’une revue. Celle-ci leur permet donc de connaître plus de parties du projet que si aucune revue n’était en place. La connaissance est moins approfondie que si le développeur travaillait en pair programming, mais tout de même.
👁️🗨️ Ce papier est intéressant, car il montre à nouveau à quel point la revue de code est un compromis entre le pair programming et l’absence totale de double-validation. Rien n’interdit à une équipe d’être souple et de passer d’une pratique à l’autre selon ses besoin.
SOURCE
Peter C. Rigby and Christian Bird. 2013. Convergent contemporary software peer review practices. In Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2013). Association for Computing Machinery, New York, NY, USA, 202–212. DOI:10.1145/2491411.2491444
Enzo Sandré
📄 Lien public DOIs: 10.1145/2491411.2491444