La programmation par paire supprime-t-elle la nécessité de réviser le code dans un projet Extreme Programming (XP)?

Dans un projet de programmation extrême, les programmeurs associent la programmation la plupart du temps.

Comme ces paires tournent également, c'est-à-dire que vous jumelez le programme avec différentes personnes et qu'il existe un sentiment de propriété collective, le code source est fréquemment revu et mis à jour.

Cela étant, est-il nécessaire de réviser le code? Je veux dire, arrêtez la programmation et effectuez simplement des révisions de code.

— Eduardo Copat
source

La programmation par paires n'est qu'un locataire de XP. Il existe de nombreuses autres méthodologies agiles qui ne suivent pas XP. Il n'y a rien dans Manifesto for Agile Software Development ni Principes derrière le Manifeste Agile qui mentionne la programmation par paires. Il n'y a rien non plus sur les revues de code. Il est important de ne pas supposer que tout agile est extrême.

Permettez-moi de reformuler ma question pour inclure uniquement XP alors.

— Eduardo Copat

Y a-t-il une raison pour laquelle vous ne l'essayeriez pas et assurez-vous de définir des critères pour arrêter? Si l'équipe est à l'aise avec l'enregistrement du code, cela devrait être une raison suffisante.

— JeffO

L'une des ressources clés pour la programmation extrême est celle de Ward's Wiki aka Portland Pattern Repository aka C2.com . C'est là qu'un certain nombre de personnes ont élaboré diverses méthodologies et les ont documentées au fur et à mesure de leur utilisation.

Dans ce wiki, il y a une page: Extreme Programming Code Reviews qui a un certain nombre de contributeurs, dont Ron Jeffries et Kent Beck.

À cela, ils ont dit:

Les revues de code sont considérées comme importantes par de nombreux gourous des grands processus. Ils sont destinés à assurer la conformité aux normes et, plus important encore, à garantir que le code est clair, efficace, fonctionne et possède un QWAN. Ils avaient également l'intention d'aider à diffuser les connaissances sur le code au reste de l'équipe.

ExtremeProgramming nécessite que tous les développements soient effectués par deux ingénieurs travaillant ensemble. Le code est en fait revu à la volée, dans une très large mesure. Cela garantit que plus d'une personne a une connaissance intime du code à tout moment.

ExtremeProgramming nécessite que tous les objets aient des UnitTests. Ceux-ci garantissent que l'objet fonctionne et continue de fonctionner tel que modifié.

Certaines langues sont réfléchissantes. Dans ces langues, UnitTests peut vérifier directement la conformité aux normes importantes. (Par exemple, les objets doivent implémenter à la fois # = et #hash, ou aucun.)

ExtremeProgramming pratique CollectiveCodeOwnership, ce qui signifie que les objets nécessitant une attention seront parcourus par de nombreux développeurs. Cela tend à exercer une pression sur ceux qui produisent du code non conforme aux normes. Les développeurs en visite sont encouragés / attendus à mettre le code en conformité lorsqu'ils trouvent des écarts. Cela garantit également que la connaissance du code est diffusée au-delà de la paire initiale de programmeurs qui l'a créée.

Par conséquent, les projets ExtremeProgramming ne nécessitent pas de revues explicites. Supprimez-les de votre méthodologie.

Il y a également un peu plus de discussion sur le sujet de la part des autres.

Cependant, avec la combinaison de tests, la propriété collaborative et la programmation en binôme, ces éléments résolvent les objectifs qu'une révision de code est généralement censée atteindre, tels que:

Diffuser la connaissance de ce qui se fait
Un deuxième (ou plus) jeu de globes oculaires sur le code pour s'assurer qu'il respecte les normes
Vérifier le bon fonctionnement du code

Celles-ci sont effectuées en continu par le biais de la programmation par paires et de tests automatisés dans Extreme Programming et une inspection explicite de Fagan n'est donc pas nécessaire.

Lecture connexe:

Programmation en binôme vs revues de code chez Coding Horror.
Les critiques de code jugées néfastes sur ExtremeProgramming.org

J'ai soutenu dans un autre Q & A que la révision de code est un gaspillage inutile (dans le sens Lean du mot) et que la programmation par paires devrait être la méthode préférée pour fournir tous les avantages qu'une révision de code fournirait. Inutile de dire que les gens ont été offensés par mon argument parce que je ne l'avais pas soutenu avec THE VOICE OF AUTHORITY (TM) comme vous l'avez fait. Pour un groupe de personnes qui font face à la logique jour après jour, nous sommes un groupe illogique.

— Michael Brown

Le risque de faire de la programmation par paires sans révisions de code supplémentaires est que les deux programmeurs sont fortement impliqués au moment de l'écriture et qu'ils peuvent écrire du code qui semble complètement clair et logique à l'époque, mais moins quand on le voit à nouveau après quelques jours. L'ampleur et / ou l'acceptabilité de ce risque dépend de votre organisation.

— Bart van Ingen Schenau

@MikeBrown, vous pourriez également affirmer que la programmation par paires est un gaspillage inutile et que la révision du code devrait etc., etc.

— AlexFoxGill

Voyez ce que je voulais dire par DÉCHETS était la définition «Lean» du mot. Pensez au processus de chaîne de montage typique. L'idée est de faire descendre la voiture le plus rapidement possible et des contrôles de qualité sont effectués après coup (révision du code). Les principes Lean supposent de prendre un peu plus de temps et d'efforts pour créer de la qualité dans (la programmation par paires), de sorte que la vérification après publication devient inutile.

— Michael Brown