Il commit / il controllo del codice ogni giorno è una buona pratica?

Non sono d'accordo con questa regola e sono d'accordo con ciò che Mason Wheeler ha detto. Vorrei piace aggiungere alcune idee.

Cerco di impegnarmi ogni volta che ho un significato cambia in commit: questo può essere più volte al giorno se risolvo diversi piccoli bug, o una volta alla settimana se sto lavorando a un software più grande che non può essere usato dal resto del codice in qualsiasi modo significativo fino a quando non raggiunge a stato coerente.

Inoltre, interpreto impegnando come pubblicando una revisione significativa che contribuisce con nuove funzionalità al codice base. Penso che si dovrebbe provare a ripulire il codice prima di impegnarsi in questo modo altri sviluppatori possono capire il significato e lo scopo del cambiamento quando guardano la cronologia delle revisioni. Meno modifiche vengono apportate ad altri sviluppatori vedere nella storia, meglio è: quando guardo la cronologia delle revisioni che voglio per vedere incrementi che aggiungono alcune funzionalità significative; non mi interessa in ogni piccola idea che ogni sviluppatore aveva e voleva provare prima di loro raggiunto la soluzione.

Inoltre, non penso che sia una buona idea usare il server SVN (o qualunque sistema di controllo della versione) come una funzione di backup a cui viene eseguita l'istantanea corrente del codice (a condizione che venga compilato): è possibile utilizzare una chiavetta USB o un'unità USB esterna o un disco di rete per rispecchiare il codice corrente in modo che non si perda se il tuo il computer si rompe. Controllo delle revisioni e backup dei dati sono due diversi cose. Pubblicare una revisione non è lo stesso di salvare uno snapshot del tuo codice.

Infine, penso che non dovrebbe essere un problema impegnarsi ogni ora e poi (cioè solo quando uno è veramente soddisfatto dello stato attuale di il codice) ed evitare conflitti di fusione non è una buona giustificazione commettendo (anche) spesso. Molti conflitti di fusione avvengono quando persone diverse lavorano sugli stessi file allo stesso tempo, che è una cattiva pratica (vedi ad esempio questo articolo , punto 7). I conflitti di unione dovrebbero essere ridotti dividendo un progetto in moduli con interfacce chiare e meno dipendenze possibili e coordinando il lavoro degli sviluppatori in modo che il codice su cui lavorano si sovrapponga il meno possibile possibile.

Solo i miei 2 centesimi.

Modifica

Un altro motivo contro i commit prematuri che mi è venuto in mente è quello una versione (molto) bacata non può essere testata. Se stai impegnando sul tronco e il tuo team di test sta testando ogni giorno, potrebbero non avere alcuna versione verificabile per alcune ore (o per un giorno). Anche se non provi a correggere il bug e basta ripristinare le modifiche, una ricostruzione può richiedere un paio d'ore. Con, diciamo, cinque tester che lavorano nel tuo team, hai sprecato 5 x 2 = 10 ore di il tempo della squadra dovuto all'inattività. Mi è successo una volta, quindi ci provo davvero per evitare commit prematuri nel nome di commit il prima possibile .

Commetto codice più volte al giorno . Ogni volta che raggiungo un punto in cui il codice è completo abbastanza da essere compilato e non rompe altre cose, va dentro.

Dovresti cercare di suddividere il tuo lavoro in modo che puoi effettuare il check-in in sicurezza alcune volte al giorno.

I motivi per questo sono due:

1. Qualsiasi lavoro non archiviato potrebbe andare perso - il tuo computer potrebbe avere un errore catastrofico. In questo caso, più a lungo aspetti, più lavori perdi.
2. Maggiore è il lavoro che svolgi senza effettuare il check-in, maggiore sarà il numero di codice che gli altri dovranno integrare quando alla fine deciderà di cuocerlo. Ciò introduce più possibilità di conflitti e unifica problemi.

Aderire in modo pedissequo a qualsiasi metodologia o pratica senza comprendere le ragioni alla base non è mai una buona idea. Ecco da dove viene la programmazione settoriale del carico.

Pertanto, "dovrei impegnarmi ogni giorno perché Martin Fowler ha detto così" è semplicemente stupido. E a volte è anche poco pratico. Se stai lavorando su una nuova funzionalità complicata, potresti non raggiungere un punto in cui vale la pena di registrarti finché non ci hai già lavorato per alcuni giorni.

Questo non significa che dovresti assicurarti che tutto sia perfetto prima di registrarlo. È un buon modo per perdere il lavoro se qualcosa va storto. La cosa corretta da fare è sviluppare e usare il buon senso in merito. Le regole pratiche ti possono aiutare moltissimo.

Oded ha fornito due importanti motivi per impegnare il codice il più frequentemente possibile. Ne aggiungerò ancora qualcuno:

1. Mentre lavori sul tuo pezzo di codice, altri potrebbero aver bisogno di alcune funzioni su quel codice. Non dovrebbero aspettare 6 giorni per ottenerlo. In questo caso i miei colleghi di solito creano un prototipo nel mio pezzo di codice, lo commettono, aggiungo il corpo e lo riprendo. E questo di solito è fatto in poche ore.

2. Il codice "comune" consente a tutti di vedere ogni modifica il più presto possibile. Se il pezzo di codice su cui stai lavorando è completamente separato dal lavoro altrui e non dovrai aspettare, allora ti consigliamo di creare un ramo su cui lavorare e, se tutto va a buon fine, unirlo a la linea principale.

Sono un strong sostenitore nell'impegnare ogni cambiamento logico che vale la pena di tenere. Impegnati spesso, e se il codice non vale la pena di essere mantenuto, ripristinalo in uno stato pulito. Più a lungo aspettate di spingere / pubblicare il vostro codice, più difficile sarà implementarlo e maggiori saranno i problemi che incontrerete. Riceverai anche un feedback sui tuoi contributi molto più rapidamente:

• interrompono la compilazione?
• stai duplicando gli sforzi di un altro membro del team?
• stai facendo qualcosa di sbagliato?
• o le persone ti stanno aspettando qualcosa?

Piccole modifiche sono molto più facili da gestire.

Inoltre, vale la pena notare la differenza tra i diversi sistemi di controllo delle versioni. Alcuni, come Git (distribuito), ti permetteranno di commettere e controllare l'intera cronologia locale, spingendo solo quando sei pronto per pubblicare. Altri, come SVN (centralizzato), combinano i due passaggi rendendo i piccoli commit molto inefficienti.

Non dimenticare che i tuoi commit sono essenzialmente documentazione di modifica. Quando le cose vanno male, sarai contento di avere più storia che non abbastanza. Un singolo impegno per un lavoro di una settimana mi sembra inutile. Mi piacerebbe solo leggere ogni singola riga di codice modificata piuttosto che il sommario di ogni singolo blocco logico.

Penso che la maggior parte delle risposte qui manchi di uno dei punti principali nella dichiarazione di Martin Fowlers. Questo è correlato a Integrazione continua . Il codice che non è archiviato (inserito / pubblicato / unito) nella linea principale non è testato.

Questo non dovrebbe essere letto come un incoraggiamento a commettere qualunque codice tu abbia nella tua macchina locale ogni volta che è ora di lasciare l'ufficio. Come sottolineato da molti altri qui che sarebbe male, rompono la build e causano una linea principale instabile.

Tuttavia, è un incoraggiamento provare a eseguire le modifiche in piccoli passaggi che possono essere archiviati sulla linea principale senza causare problemi. Questo incoraggia l'evoluzione del codice anziché rimuoverlo a parte e riscrivere.

Ora, cosa c'è di buono in questo modo di lavorare?

1. Non commettere grandi pezzi di codice o modifiche rivoluzionarie riduce la possibilità di rompere la build.
2. Se il tuo commit interrompe la compilazione, è piuttosto semplice identificare quali sono i problemi, ripristinarli e poi eseguire rapidamente una versione fissa.
3. Assicurandoti che tutti i test siano eseguiti su ogni piccola modifica del codice, assicurati di non introdurre bug o regressioni sottili che potrebbero derivare dall'avere un codice in crescita al di fuori dello schema di integrazione continua.

Naturalmente non tutti i cambiamenti si prestano a questo approccio. Come altri hanno sottolineato, nessuna regola è assoluta. Tuttavia, per le modifiche che dovrebbero rimanere fuori dalla linea principale per un lungo periodo, impostare una mainline alternativa con il proprio schema di integrazione continua e seguire lo stesso approccio verso di essa. Con i VCS distribuiti di oggi è una cosa abbastanza facile da fare.

Argomenti per il check-in ogni giorno:

Il codice
• viene archiviato e sottoposto a backup dall'errore dell'harddrive
• L'attività può essere registrata nelle note di commit ( cosa ho fatto giovedì ...? )
• L'integrazione con il code base esistente avviene prima e in blocchi più piccoli, si spera di identificare i conflitti o unire i problemi prima
• Il tuo team ha visibilità di ciò su cui hai lavorato
• I tuoi colleghi possono lavorare prima contro le tue interfacce, dando loro più tempo per integrarsi con il tuo "grande complesso bit di codice"
• Il tuo codice verrà testato prima del mondo reale, o almeno sarà esposto a un uso più ampio di quello che gli darai, portando a una precedente identificazione di bug o omissioni.

Argomenti contro il check-in ogni giorno:

• Non è necessario o non vuoi
• Non ho ancora "ripulito" il mio codice, è un casino
• Non avere tempo

Non credo che ci sia una buona ragione per fare il check in meno di ogni giorno, a parte la pigrizia o la disorganizzazione. Niente di peggio che vedere il codice in esecuzione nell'ambiente di sviluppo non corrisponde al codice nel ramo di sviluppo perché qualcuno "non ha ancora finito" e quindi non ha effettuato il check in.

Mi piacerebbe esserci di sbagliato su questo quindi per favore fatemi sapere qualsiasi argomento legittimo contro il check-in giornaliero.

Se intendi "commit" come "unisci in mainline", non dovresti assolutamente farlo ogni giorno su un progetto software che viene rilasciato ai clienti. Dovresti unire le modifiche che sono state fatte e testate, in modo che la linea principale sia sempre funzionante e rilasciabile, e non in uno stato non funzionante con funzionalità semi-rifinite.

Tuttavia, il lusso di lavorare con il controllo delle versioni distribuite di oggi è che puoi sia mantenere la linea principale stabile, sia allo stesso tempo fare il tuo git/hg/whatever commit ogni volta che ritieni di voler conservare lo stato delle cose. Lo faccio una volta ogni poche ore e sicuramente alla fine di ogni giorno.

Con DVCS, puoi pubblicare il tuo lavoro, collaborare con gli altri del tuo team e tenerlo aggiornato con le modifiche nel ramo principale. Puoi fare tutto questo senza inquinare la stabilità del codice su cui i tuoi clienti e / o altri team dipendono.

In tempi in cui Subversion era la tecnologia più recente e non c'era modo di inserire e unire rami di feature senza estremo dolore, avere un mainline in cui diverse feature erano in costruzione simultanea poteva essere l'approccio migliore. Ma questa superiorità non supera il 2010.

In Team Foundation Server puoi "Shelve" che non è la stessa cosa di un check in, ma fa solo un backup del tuo codice in modo che se la tua macchina muore non hai perso le modifiche.

Ho anche visto case software che hanno una "linea di sviluppo" e una "linea principale". Gli sviluppatori sono liberi di registrarsi alla linea di sviluppo ogni volta che lo ritengono opportuno e solo il capo squadra ha accesso alla linea principale in modo che siano responsabili della copia del codice da dev a main quando è pronto per la produzione.