Extreme Programming Daily Commits [chiuso]

Daily ?? Se stai seguendo questa strategia, dovresti impegnarti molto più spesso di così.

L'idea è che ti impegni presto. Impegnati spesso. Sincronizzazione spesso Rendi i commit piccoli e facili da recensire. I conflitti avvengono perché 2 persone lavorano in modo indipendente sulla stessa cosa: quando lavori in piccole unità veloci la finestra del conflitto diventa molto più piccola. E i conflitti rimanenti sono minuscoli e facili da risolvere perché tutti hanno ancora uno stato mentale. (In contrasto con lo standard del settore di cercare di districare grandi conflitti 6 mesi dopo la linea.)

Lo svantaggio è che puoi essere infranto da qualcun altro che lavora lontano da te in azienda. Inoltre rende difficile lavorare su filiali che potrebbero o meno voler entrare in produzione. Molte persone pensano anche che non sia una strategia scalabile: le grandi organizzazioni hanno bisogno di pratiche più sofisticate.

Non sono d'accordo con quella critica. Per un punto di riferimento, in Google tutte le modifiche devono essere sottoposte a peer review prima di essere impegnate. Il commit medio è inferiore a 20 righe. I commit avvengono direttamente sul ramo principale. Vi sono numerosi test unitari e test di integrazione che vengono eseguiti automaticamente prima che il commit possa concludersi. (Con un'infrastruttura per far sì che ciò avvenga in modo accettabile.) La saggezza ricevuta da Google è che queste pratiche sono state ridimensionate con successo su Google. Tuttavia, se togli qualcuno di quei pezzi, non lo farebbe.

Penso che i commit quotidiani (o più) siano una buona pratica di ingegneria del software in generale, indipendentemente dalla metodologia utilizzata. Alcuni vantaggi (in nessun ordine particolare)

• Tempo di tracciamento il tuo log di commit diventa un'ottima fonte di "cosa ho fatto martedì" quando ho compilato la tua scheda attività poco prima della scadenza del prossimo lunedì.
• Verifica / Sanity check se stai utilizzando l'integrazione continua, un check-in richiederà una build che ti dà la conferma che il tuo codice (per lo meno) non interrompe la build. (Aggiungi in TDD e test automatici di fumo, e ottieni ancora più validità).
• Più piccoli lotti che lavorano in piccoli lotti giornalieri, riducono il carico cognitivo. Invece di pensare a tutto ciò che devi fare su questo sprint attuale, puoi concentrarti su ciò che stai facendo oggi.
• Ridurre al minimo l'impatto della legge di Murphy Ho avuto dischi rigidi morti senza una ragione apparente. Pensa al tuo check-in come backup. Quanto lavoro sei disposto a perdere quando (non se) il tuo hardware locale ti colpisce?

Alcuni svantaggi dei check-in meno frequenti

• Unisci più a lungo mantieni un file e più file reggi, più è probabile che le tue modifiche siano in conflitto con le modifiche di un altro sviluppatore che richiedono un'unione
• Andando al buio senza effettuare il check-in, i tuoi compagni di squadra non hanno alcuna visibilità su ciò che stai facendo.
• Al contrario, tutti i vantaggi perdi tutti i vantaggi di impegnarti quotidianamente o più frequentemente.

Il concetto di fare commit quotidiani (se non più spesso) deriva dall'idea di Integrazione continua . L'idea di base di CI è che gli sviluppatori dovrebbero integrare le loro modifiche più volte al giorno, eliminando così la norma storica di ognuno che si sviluppa da solo per diverse settimane, passando poi diversi mesi cercando di integrare tutti i loro diversi pezzi. La maggior parte degli strumenti di configurazione automatica automatizza il processo di creazione delle modifiche al codice e l'esecuzione di suite di test di unità, quindi gli sviluppatori hanno poco onere.

Con quello come sfondo, ecco le risposte dirette alle tue domande.

What are the benefits of [committing all changes before going home]?

• Permette l'integrazione continua, che è una buona cosa.
• Minori possibilità di perdere il tuo lavoro (se usi repository non sul tuo computer)
• Avere un modo semplice per ripristinare qualcosa se hai fatto un errore
• Rendi le modifiche disponibili per altri sviluppatori.

What are the risks of not [committing all changes before going home]?

• Si perde qualcosa a causa di un arresto anomalo del disco rigido.
• Perdi qualcosa perché hai cancellato o modificato accidentalmente la cosa sbagliata.
• Non sai che hai problemi di integrazione finché non è davvero difficile risolverli.
• Il tuo codice non viene testato nel contesto di altre parti del codice.

Mi sento in dovere di sottolineare che "commettere tutti i cambiamenti prima di andare a casa" non è necessariamente qualcosa che dovresti fare. Quando la tua mente lo ha già chiamato un giorno, rischi di rompere la costruzione, commettendo qualcosa e poi lasciando rapidamente l'ufficio. Considera prima queste domande:

• Hai compilato il codice?
• Hai eseguito tutti i test unitari del progetto per assicurarti che tutto funzioni?
• Stavi lavorando sul tuo ramo personale invece del master?
• Stai utilizzando uno strumento che mostra se hai dimenticato di includere qualcosa nel tuo commit?

Dopo aver rotto la build molte volte e aver visto gli altri farlo abbastanza spesso, non commetto le mie modifiche prima di andare a casa se rispondo "no" a nessuna di quelle domande. Detto questo, sono a favore di micro commit e impegno almeno ogni ora. Basta non impegnarsi se hai già messo il cappotto.

Tra le molte attività di XP una di queste è RESPECT che afferma:

I programmatori non dovrebbero mai commettere modifiche che interrompono la compilazione, che fanno fallire i test unitari esistenti o che ritardano il lavoro dei loro colleghi

What are the benefits of following this

• Sai quanto lavoro è svolto e amp; quanto rimane da fare.

• Altre ppl hanno un accesso più veloce al tuo codice (meno tempo di attesa).

• Più facile da individuare se un programmatore esegue correttamente l'attività.

• Integrazione del codice più facile e veloce.

• Esegui l'integrazione continua + test dell'unità.