La programmazione di coppia rimuove la necessità di revisioni del codice in un progetto Extreme Programming (XP)?

In un progetto di programmazione estrema, i programmatori accoppiano la programmazione per la maggior parte del tempo.

Poiché anche queste coppie ruotano, vale a dire che abbini un programma a persone diverse e c'è un senso di proprietà collettiva, il codice sorgente viene frequentemente rivisto e aggiornato.

Essendo così, c'è bisogno di revisioni del codice? Voglio dire, smetti di programmare e in realtà fai semplicemente delle revisioni del codice.

— Eduardo Copat
fonte

La programmazione della coppia è solo un tenant di XP. Esistono molte altre metodologie agili che non seguono XP. Non c'è nulla nel Manifesto per lo sviluppo di software Agile né Principi dietro il Manifesto Agile che menziona la programmazione di coppie. Non c'è nemmeno nulla sulle recensioni dei codici. È importante non supporre che tutto agile sia estremo.

Consentitemi di riformulare la mia domanda per includere solo XP.

— Eduardo Copat,

C'è un motivo per cui non lo proveresti e assicurati di impostare alcuni criteri per smettere? Se il team è a proprio agio con il codice che sta effettuando il check-in, questo dovrebbe essere un motivo sufficiente.

— JeffO,

Una delle risorse chiave per Extreme Programming è quella del Wiki di Ward aka Portland Pattern Repository aka C2.com . Qui è dove un certo numero di persone ha eliminato varie metodologie e le ha documentate mentre le usavano.

All'interno di questa wiki, c'è una pagina: Extreme Programming Code Reviews che ha un certo numero di collaboratori, tra cui Ron Jeffries e Kent Beck.

A questo, hanno detto:

Le revisioni del codice sono considerate importanti da molti guru di grandi processi. Hanno lo scopo di garantire la conformità agli standard e, soprattutto, di garantire che il codice sia chiaro, efficiente, funzionante e dotato di QWAN. Intendevano anche aiutare a diffondere la conoscenza del codice al resto del team.

ExtremeProgramming richiede che tutto lo sviluppo venga svolto da due ingegneri che lavorano insieme. Il codice è in realtà rivisto al volo, in misura abbastanza grande. Ciò garantisce che più di una persona abbia una conoscenza intima del codice in ogni momento.

ExtremeProgramming richiede che tutti gli oggetti abbiano UnitTest. Questi assicurano che l'oggetto funzioni e continui a funzionare come modificato.

Alcune lingue sono riflettenti. In tali lingue, UnitTest può verificare direttamente la conformità agli standard importanti. (ad esempio, gli oggetti devono implementare sia # = che #hash, o nessuno dei due.)

ExtremeProgramming practice CollectiveCodeOwnership, il che significa che molti sviluppatori dovranno esplorare gli oggetti che richiedono attenzione. Ciò tende a esercitare pressioni su coloro che producono codice non conforme agli standard. Gli sviluppatori in visita sono incoraggiati / tenuti a rendere il codice conforme quando trovano deviazioni. Ciò garantisce anche che la conoscenza del codice sia diffusa al di là della coppia iniziale di programmatori che lo hanno creato.

Pertanto, i progetti ExtremeProgramming non richiedono revisioni esplicite. Eliminali dalla tua metodologia.

C'è anche un po 'più di discussione sull'argomento lì da altri.

I punti chiave, tuttavia, sono che con la combinazione di test, proprietà collaborativa e programmazione in coppia queste cose risolvono gli obiettivi che una revisione del codice dovrebbe in genere fare come:

Dispersione della conoscenza di ciò che viene fatto
Un secondo (o più) set di bulbi oculari sul codice per assicurarsi che rispetti gli standard
Verificare il corretto funzionamento del codice

Questi vengono eseguiti continuamente attraverso la programmazione di coppie e test automatici nella programmazione estrema e pertanto non è necessaria un'ispezione esplicita di Fagan .

Lettura correlata:

Associa programmazione a recensioni di codice su Coding Horror.
Recensioni del codice considerate dannose su ExtremeProgramming.org

Ho sostenuto in un'altra domanda e risposta che la revisione del codice è uno spreco non necessario (nel senso Lean della parola) e che la programmazione di coppie dovrebbe essere il metodo preferito per fornire tutti i vantaggi che una revisione del codice fornirebbe. Inutile dire che la gente si è offesa per la mia tesi perché non l'avevo sostenuto con THE VOICE OF AUTHORITY (TM) come te. Per un gruppo di persone che affrontano la logica giorno dopo giorno, siamo un gruppo illogico.

— Michael Brown,

Il rischio di eseguire la programmazione di coppia senza ulteriori revisioni del codice è che entrambi i programmatori sono fortemente coinvolti al momento della stesura e possono scrivere un codice che sembra completamente chiaro e logico al momento, ma meno se visto di nuovo dopo pochi giorni. Quanto è grande e / o accettabile tale rischio dipende dalla tua organizzazione.

— Bart van Ingen Schenau,

@MikeBrown potresti anche sostenere che la programmazione delle coppie è uno spreco inutile e che la revisione del codice dovrebbe ecc.

— Ecc

Vedi cosa intendevo con WASTE era la definizione "magra" della parola. Pensa al tipico processo della catena di montaggio. L'idea è di far scendere la macchina il più rapidamente possibile e dopo il fatto vengono effettuati controlli di qualità (revisione del codice). I principi magri prevedono un po 'più di tempo e sforzi per migliorare la qualità (programmazione in coppia) in modo che il controllo post diventi superfluo.

— Michael Brown,