La programmazione delle coppie si trasforma mai in lunghe discussioni improduttive?

A volte le discussioni difficili sono un effetto collaterale della programmazione delle coppie, ma non sempre è una cosa negativa. Come discussione su quale approccio prendere significa che stai pensando al codice prima di scriverlo e hai più di un set di occhi su di esso.

Tratto da: link :

The ideal pairing situation requires both people to be expert developers. They need to be open to the other person's idea. And in this case (expert developers with good, strong opinions), its likely to bring pain.

Tuttavia, le "guerre religiose", se si verificheranno, verranno presentate in una revisione del codice o altrove, se non vengono presentate le paia di programmazione. Evitare discussioni improduttive è qualcosa che deve essere identificato ed evitato in qualsiasi aspetto della programmazione. Il modo principale per evitarlo è quello di concentrarsi sull'ottenere il lavoro completato, imparare a scegliere soluzioni che soddisfano molteplici problemi e imparare a cedere quando una scelta non vale il tempo necessario per discuterne.

Non ho fatto un sacco di programmi di coppia, e in genere lo riservo per i casi in cui sono davvero bloccato o problemi di progettazione importanti. Queste sono proprio le situazioni in cui le discussioni si presentano, comunque. Questa è la mia esperienza:

• Grandi discussioni si verificano sia che tu stia programmando una coppia, oppure no. La differenza sta nel fatto che la programmazione in coppia li porta in superficie più presto e ottiene più cervello lavorando sul problema immediatamente. Per questo motivo, tendo a cercare un partner di programmazione quando prendo decisioni di codice che sono importanti e difficili.
• Le discussioni riscaldate non sono generalmente rivolte tanto l'una all'altra quanto al problema. Quando il problema è scomparso o reso perseguibile (ad es., "Facciamo un incontro per risolvere il problema"), i sentimenti negativi sono andati e finiti.
• Le discussioni riscaldate indicano che le persone si preoccupano del problema e vogliono trovare una soluzione. Questo tipo di passione porta spesso alla creatività e alle grandi soluzioni.
• I vantaggi della programmazione delle coppie non solo superano il rischio di frustrazione, ma isolano da tale rischio. Il successo e il buon codice possono cancellare un sacco di frustrazioni o sentimenti duri.
• Vedo discussioni più accese quando una persona codifica da sola e va nella direzione sbagliata. A quel punto, il programmatore ha investito molto nella direzione sbagliata, e richiede molto più carattere per ammettere di dover rifare una grossa fetta di lavoro piuttosto che rifare alcune righe di codice o una bozza del progetto.
• Le "guerre sante" sono in genere risolte dalla compagnia o dalla preferenza di gestione, dalla discussione razionale sui pro e contro o sull'anzianità. Le guerre sante che non possono essere risolte da uno di questi di solito indicano che qualcuno è un pessimo adattamento per la compagnia, e l'argomento della guerra santa alla fine sarebbe diventato una fonte di attrito anche senza la programmazione delle coppie. Un ricorso a un'altra autorità può spesso aiutare a risolvere questi problemi, ad esempio, decidiamo di farlo decidere al nostro capo / al cliente.

Tipicamente quando accoppio il programma e viene fuori un importante punto di discussione facciamo del nostro meglio per metterlo da parte per una discussione separata. Ci saranno cose che non sono state prese in considerazione durante l'elaborazione del progetto iniziale, o opinioni divergenti su come implementare qualcosa. È meglio continuare la sessione di programmazione andando avanti, poiché questi tipi di discussione possono essere gestiti con mezzi più produttivi rispetto a quelli di smack nel bel mezzo della programmazione di coppie.

Quelli al prossimo cubicolo sopra il mio sembrano SEMPRE finire in quel modo.

Nella mia esperienza, la programmazione di coppie è stata fatta come parte di un approccio generale "estremo", in cui l'obiettivo a breve termine è quello di mettere in piedi qualcosa, con la consapevolezza che il refactoring deve essere fatto in seguito. Detto questo, le possibili discussioni accese tendono a risolversi con qualcuno che dice "Bene, bene, lo codificheremo per ora e vediamo come va, possiamo sempre cambiarlo più tardi."