Come si può ottenere e mantenere il flusso durante la programmazione delle coppie?

Modifica: Disclaimer: ecco come definisco "la zona": A state of extreme focus, in which one is able to understand how many intricate details connect together, regardless of whether these do so elegantly (or simply) or not.

Cerco di evitare questo stato perché, mentre posso produrre codice corretto nella zona, io e altri sviluppatori avremo difficoltà a capirlo in seguito. Per dirla in breve: leggere il codice che è stato scritto nella zona può spesso richiedere che il lettore si trovi nella zona. Quel vincolo è il mio problema.

C'è un bel capitolo su The Clean Coder dove lo Zio Bob spiega in modo convincente perché "entrare nella zona" è una cattiva idea.

Ecco un'alternativa forse migliore di "entrare nella zona": pensa bene e considera con calma e professionalità quello che stai facendo. Comunicare. Condividi pensieri con il / i tuo / i partner / i. Identifica i problemi reali. Discutere possibili soluzioni. Potresti non sentirti concentrato in modo supernaturale, ma è probabile che tu prenderai buone decisioni e disegni accessibili.

Se tu e il tuo partner di coppia potete discutere il problema senza che voi siate estremamente concentrati, è probabile che abbiate ridotto il problema alla sua natura più semplice. Ciò suggerisce che sarai in grado di capirlo nuovamente ogni volta che ne avrai bisogno.

Il rovescio della medaglia ... Se hai solo bisogno di un po 'di tempo da solo per avere la testa dritta (lo facciamo tutti a volte), prendilo. Metti insieme i tuoi pensieri. Prima risolvi il problema nella testa.

Ma la cosa è che se lo fai - non usare quel tempo per scrivere il codice di produzione. Invece, giocare con codice di esempio e prototipi. Cerca di capire il problema, senza pensare ancora alle soluzioni. Una volta che tutto è scritto e scritto, discutine con la tua squadra e il tuo partner, o anche con l'anatra di gomma sulla tua scrivania. Se ancora non riesci a articolarlo o non riesci a capirlo, raffina le tue idee. Una volta individuato tutto ciò, integra tutto quel pensiero e codice di esempio in una soluzione reale e funzionante.

La programmazione accoppiata a volte richiede periodi di isolamento dal tuo partner.

Esempio

Stai lavorando insieme su una particolare classe e ti rendi conto che devi scrivere un metodo che richiede una riflessione approfondita su una logica complessa, ma che altrimenti restituisce un risultato banale. Lavorate insieme sulla creazione di test unitari per quel metodo e rimandate la scrittura di quel metodo in un periodo di tempo in cui state lavorando in isolamento. Quando il metodo è completato, torni insieme come una coppia e valuta i risultati.

Ho scoperto che esiste una piccola classe di problemi per i quali funziona la programmazione della coppia. Ad esempio, se si sta lavorando su un prodotto multipiattaforma e il ragazzo Winders ha implementato una funzionalità che richiede codice specifico del sistema operativo, può aiutare il ragazzo Mac a implementare la stessa funzione sul codice Mac mentre il Mac fa la guida.

Tuttavia, secondo la mia esperienza, la programmazione di coppie ha come risultato una perdita netta di produttività. Spesso sembra che stiamo pagando due sviluppatori per fare il lavoro di uno.

Sì, riduce la terrificante possibilità che un dev possa prendere una pausa stackexchange durante il giorno lavorativo.

IMHO sarebbe più economico per quelle aziende che vogliono controllare i loro sviluppatori per accoppiare ogni dev con una guardia di sicurezza privata per stare dietro allo sviluppatore e colpire il dev con un manganello se mai rallenta o cerca di raggiungere un picco pagina web non essenziale.

Quando uno sviluppatore tenta di entrare nella zona, tenterai di isolarti nel miglior modo possibile per metterti comodo e liberare la mente. Perché la programmazione della coppia dovrebbe essere diversa?

Tu e il tuo partner dovreste trovare un ambiente che induca alla zona e che funzioni per entrambi. Ciò richiederà probabilmente un compromesso su alcune cose, ma il mio punto principale è che l'ambiente di coppia dovrebbe essere simile al solo. Spegni il mondo esterno. La coppia sta programmando insieme; altre coppie (altri colleghi in generale) non dovrebbero essere interrotte (eccetto i problemi critici, drop-what-you-are-doing).

Il flusso è un grande stato in cui essere quando si conoscono i passaggi esatti per risolvere un problema. cioè pochi sconosciuti sconosciuti. Ti siedi in un angolo tranquillo e martella via la soluzione. Tuttavia, molti problemi / storie / caratteristiche non sono molto chiari quando si inizia a programmarli. Ci sarà sempre un "vuoto" tra lo stato finale atteso e il modo in cui il tuo cervello lo ha "programmato". Impari molte cose quando in realtà "fai". Il tuo cervello si destreggia.

• Progettazione codice

• Digitando

• Imparare nuove cose sul dominio e sul codice

Quando programmo da solo, faccio fatica a bilanciare queste cose. Tendo ad entrare nei "buchi dei conigli" dove il mio errore di costi irrisolti mi impedisce di fare un passo indietro e guardare il quadro generale e cambiare il mio progetto. È anche difficile per me parlare con un'anatra di gomma immaginaria o con uno vero per quella materia. Dopotutto sono in "flusso".

Quando sto programmando una coppia produttiva, riesco a alternare periodi di digitazione seguiti da periodi di riflessione e riflessione. È qui che molte cose nascoste si rivelano e può emergere un design diverso. Se vado in una tana di coniglio, il mio compagno di coppia può tirarmi fuori da esso. Parlare / spiegare qualcosa a un vero essere umano ha questo meraviglioso effetto di rendere i tuoi pensieri più chiari in qualche modo. A volte, mi manca di essere nel "flusso", ma penso di contribuire molto di più alla mia squadra quando accoppio il programma rispetto a quando programmo da solo. Dopo tutta la programmazione! = Digitando. La programmazione avviene nel cervello e una programmazione migliore avviene quando due cervelli collaborano e si criticano a vicenda.