La programmazione accoppiata significa che non è necessaria la documentazione di progettazione?

Question

Nella programmazione pair, l'esperienza di ogni membro del team può essere estesa a un nuovo membro. Questa esperienza è sempre sincronizzata con il codice, perché il "senior" della coppia sa come funziona il codice e qual è il design.

Quindi, qual è l'utilità della documentazione di progettazione in questo caso?

UPDATE

io non implicano nessun disegno, ho implica alcuna documentazione. Con una squadra che pratica la programmazione delle coppie, penso che tutti siano usa e getta, perché tutti conoscono il codice. Se lo sviluppatore senior se ne va, penso che ci sia sempre almeno una persona che conosce il codice, perché l'esperienza è stata condivisa in precedenza.

Answer 1

E se la tua squadra è più grande di 2 persone?

Solo perché due persone conoscono una parte di un sistema non significa che non dovrebbe essere documentato.

E sarei felice di sapere che non devo ricordare ogni piccolo dettaglio di un sistema solo perché è memorizzato in nessun altro posto che nella mia testa.

Per un sistema di piccole dimensioni questo potrebbe funzionare, ma man mano che il sistema si ingrandisce, limiterete voi stessi e i vostri colleghi. Preferirei usare la capacità di memoria per un nuovo sistema piuttosto che ricordare tutto il vecchio sistema.

Answer 2

Chi conosce il codice scritto per primo? La risposta è nessuno lo sa, perché non è stato scritto. Il motivo per cui non è stato scritto è perché nessuno sa cosa fare, quindi la necessità di un documento di progettazione.

Answer 3

Avete mai suonato "telefono?" Non penso che dovresti giocare con il tuo codice base.

Answer 4

E se il programmatore anziano lascia la società/il progetto?

Answer 5

La base di codice può essere così grande che non è possibile ricordare umanamente ogni dettaglio di ciò che si intendeva implementare. Un riferimento è utile in questo caso.

Inoltre, è necessario un disegno se si interagisce con altri componenti, ecc

Answer 6

manutenzione. Non puoi aspettarti che la squadra rimanga statica, perché non ci saranno nuovi membri o la perdita di vecchi membri. La documentazione di progettazione garantisce che coloro che sono nuovi al progetto, che devono mantenerlo per anni, abbiano informazioni sulle decisioni prese, sul perché sia ​​stato scelto l'approccio e su come deve essere implementato. È molto importante per il successo a lungo termine di un progetto avere questa documentazione, che può essere fornita tramite una combinazione di documenti tradizionali, commenti di origine, test unitari e vari altri metodi.

Answer 7

Pair Programming consente solo la codifica e l'aspetto logico.

Ma la documentazione è una buona pratica. Sempre fare documentazione ...

Answer 8

Il set di prodotti deve essere deciso indipendentemente dal fatto che si utilizzi o meno la programmazione di coppie.

Sei mesi o due anni dopo, tutte le persone coinvolte potrebbero trovarsi in un progetto diverso (o una società diversa).Vuoi essere in grado di tornare e utilizzare la documentazione di progettazione? Quindi, produrlo. Se non vuoi tornare, o il design è abbastanza semplice che con le specifiche e il codice puoi capirlo senza l'aiuto di un documento di design esplicito, puoi saltarlo.

Ma non affidarti alle due persone che ti spiegano il design un anno dopo.

Answer 9

Non vedo che la programmazione di coppia rende obsoleta la documentazione di progettazione. Devo immediatamente pensare allo Truck factor. Certo, l'anziano potrebbe sapere qual è il progetto. Ma cosa succede quando è malato? Cosa succede quando il suo viene colpito da un camion con il? E se fosse licenziato?

La programmazione di coppie diffonde conoscenza, ma non fa mai male documentare quella conoscenza.

Answer 10

Beh, se volete un foglio di calcolo, invece di un word processor un uso di progettazione doc utile :-)

XP, pair programming, agile, ecc ... non significa che non si dispone di un piano, esso è solo un piano molto meno dettagliato (a livello micro) di ciò che sta accadendo. I casi d'uso che l'utente sceglie sono più del design, ed è più un documento vivente che con altri stili di design/programmazione.

Non cadere nella trappola perché, facendo qualcosa di "bello", non hai più bisogno di buone pratiche - in effetti questo stile di programmazione richiede più disciplina piuttosto che meno per avere successo.

Answer 11

La programmazione di coppie è composta da due persone che condividono un computer. Di per sé, non dice nulla su che tipo di metodologia di progettazione utilizza la coppia (s).

La programmazione di coppie, quando si esegue come parte di "ExtremeProgramming", significa seguire le linee guida di programmazione Extreme per la progettazione. Questo in genere comporta la raccolta e la codifica in "storie degli utenti". Queste storie sarebbero quindi al posto di altri documenti di progettazione.

Answer 12

L'esperienza delle persone potrebbe essere sincronizzata con il codice, come dici tu. Ma le decisioni sul design non sono tutte catturate nel codice - solo le scelte fatte ci sono.

Nella mia esperienza, per capire veramente perché il codice è stato progettato così com'è, è necessario conoscere le scelte di progettazione che non sono state selezionate, gli approcci che avevano provato e fallito ecc. Si può sperare che i "bisbigli cinesi" "catena trasmette quello correttamente, dato che non c'è alcuna registrazione di questo nel codice per aggiornare i ricordi o correggere errori ...

... oppure puoi scrivere della documentazione sul design e su come è arrivato. In questo modo, eviterai di essere portato giù in un vicolo buio dai programmatori di manutenzione in futuro.

Answer 13

La programmazione di coppie è un'opportunità per il team di evitare di dover dedicare gran parte del tempo di progetto alla documentazione di tutto. Ma la necessità di documentazione dipende da quanto sei bravo a ricordare le cose importanti e quanto è buono il tuo codice. Si può ancora volere molta documentazione se il codice è difficile da lavorare.

Si potrebbe provare alcuni esperimenti: -

• Documento un paio di piccole parti del progettazione e notare quanto spesso si deve fare riferimento ad esso.
• Documenti che fanno sempre male con cui lavorare.

Answer 14

No Né la mancanza di programmazione della coppia significa che è necessaria la documentazione. La documentazione è necessaria! Quello che sembra potrebbe sorprenderti!

Un team agile deciderà quando e quale documentazione è necessaria. Una buona regola generale, se nessuno lo leggerà, non scriverlo. Non farti coinvolgere nel pensiero artefatto cascata fornendo artefatti perché il Project Manager lo dice.

La maggior parte pensa alla documentazione come qualcosa che si fa con Word. Se un team agile funziona correttamente, il codice stesso, con TDD (sviluppo guidato dai test), avrà una serie di test automatici che documentano e fanno rispettare i requisiti. Immagine, documentazione sincronizzata con il codice ... e rimane così.

Detto questo, l'associazione aiuta il dominio, l'applicazione, la pratica e le conoscenze di abilità che si propagano attraverso il team molto rapidamente. L'abbinamento aiuta inoltre a garantire che il team segua le pratiche di ingegneria, tra cui TDD e altri test automatici. I risultati sono che l'applicazione rimane sana e il cambiamento futuro è facile da realizzare.

Così, la linea di fondo, la programmazione di coppie produce una documentazione migliore. Non elimina la documentazione (anche se potresti non essere in grado di trovare un documento Word).

Answer 15

Sono un pro-avvocato e un fan della documentazione. La programmazione delle coppie non richiede "uno sviluppatore senior". Nella mia esperienza con la programmazione delle coppie, gli sviluppatori di tutti i livelli sono accoppiati, allo scopo di un rapido sviluppo. Ci sono molte volte in cui ho lavorato con sviluppatori junior e mi sarei scambiato sulla tastiera. Ci sono molte volte in cui ho lavorato con architetti senior e mi sarei scambiato sulla tastiera. La documentazione è ancora necessaria, specialmente con i componenti principali e il database.

Answer 16

Dipende da cosa si intende per "documentazione di progettazione".

Se si dispone di test funzionali - in particolare i test di comportamento-driven di sviluppo (BDD), o Fitnesse o test FIT poi sono certamente una forma di "documentazione attivo" ... e certamente hanno un valore così come essere test di regressione

Se si scrive storie di utenti e li abbattere in compiti e scrivere quelle compiti sulle schede per le coppie a fare allora stai facendo una forma di documentazione ...

Queste sono le due principali forme di documentazione che ho usato nei team XP che si accoppiano su tutto il codice di produzione.

L'unico altro documento che trovo molto utile è una mezza pagina o così un set di punti elenco che mostrano agli utenti come configurare l'ambiente di costruzione per un computer di sviluppo. Dovresti mantenere la lista man mano che la usi.