Conservazione della cronologia del commit del controllo delle versioni vs Refactoring e Documentazione

Naviga le tue risposte
10

Non costa quasi nulla usare la cronologia dei commit mantenuta dal sistema di controllo della versione. Tuttavia, durante uno sforzo importante di refactoring (o riorganizzazione / pulizia), le funzioni, le classi e persino i namespace verranno spostati; a volte diversi file verranno uniti insieme e altri file verranno suddivisi. Queste modifiche spesso portano alla perdita della cronologia di commit originale di alcuni file.

Secondo la mia opinione personale, l'aggiornamento dell'organizzazione del progetto è più importante della conservazione della cronologia del codice sorgente. Una buona organizzazione del progetto consente di aggiungere continuamente nuove funzionalità con uno sforzo ragionevole, mentre il valore della cronologia del codice sorgente sembra dubbio.

Inoltre, con l'uso del test delle unità, i problemi di regressione vengono rapidamente identificati. Finché l'ultima versione continua a soddisfare tutti i requisiti del software, dobbiamo effettivamente conservare la cronologia del codice sorgente?

Comprendo che qualsiasi codice sorgente spedito deve essere conservato a causa della necessità di fornire supporto ai clienti senza richiedere loro di eseguire un aggiornamento della versione principale. Ma a parte questo, c'è qualche valore nel mantenere la cronologia del codice sorgente commessa?

La cronologia del commit del codice sorgente ha alcun ruolo nelle comunicazioni tra i membri del team? Cosa succede se aboliamo la cronologia dei commit, ma ci affidiamo invece a "codice sorgente" + "codice test unità" per la comunicazione?

L'esistenza della cronologia dei commit rende compiacenti la documentazione a lungo termine di informazioni importanti sul progetto, come i principali cambiamenti di progettazione / requisiti e i flussi di pensiero che hanno guidato tali cambiamenti?

    
posta rwong 24.01.2011 - 06:19
fonte

3 risposte

5

Per utilizzare la cronologia del commit per più di commenti di tipo "modifiche apportate" o "bug corretti", è necessario collegarlo al sistema di tracciamento dei problemi. Ogni modifica, ogni commit, dovrebbe avere qualche problema associato in modo da sapere cosa è cambiato, da chi e perché.

As long as the latest version continues to satisfy all of the software requirements, do we actually need to preserve the history of the source code?

Un software sufficientemente complesso ha raramente tutti i requisiti implementati e tutti i bug risolti per una moltitudine di ragioni, quindi penso che la tua affermazione qui sia, diciamo, ottimista.

Supponiamo che tu sia nella versione 7.8 del tuo programma. Ma stai supportando, sul campo, 12 diverse versioni attive, come 1.6, 2.2, 2.8 e così via. Ognuno di questi non verrà aggiornato alla versione più recente per una serie di motivi, quindi stai supportando tutti con correzioni di bug. Un cliente trova un bug nella tua ultima versione 7.8. Lo aggiusti in 7.8. Come fai a sapere quante altre versioni devono essere corrette?

senza la cronologia delle fonti e il monitoraggio dei problemi     
risposta data 24.01.2011 - 07:59
fonte
7

the value of source code history appears to be dubious.

Ho avuto ingegneri indietro di diversi anni nel codice sorgente alla ricerca di risposte sul perché qualcosa è così com'è. A volte il modo in cui le cose si sono evolute nel tempo è importante per capire un bug, ma non è qualcosa a cui si pensa tipicamente quando si documentano le cose (e nemmeno necessariamente sono documentabili).

Inoltre, ci possono essere ottimi motivi legali per mantenere la cronologia del codice sorgente. La maggior parte dei dumpster-diving del codice sorgente che ho dovuto fare (come build / SCM engineer) è stata richiesta dal dipartimento legale della mia azienda.

    
risposta data 27.01.2011 - 01:34
fonte
3

As long as the latest version continues to satisfy all of the software requirements, do we actually need to preserve the history of the source code?

But aside from this, is there any value in keeping the history of source code commits?

Sì ad entrambi. Può essere utile sapere quando qualcosa è cambiato, da chi e perché. Se perdi la cronologia, la tua capacità di farlo è influenzata.

Does source code commit history play any role in the communications between team members? What if we abolish the commit history, but instead rely on "source code" + "unit testing code" for communication?

Sì, lo fa. Il solo approccio "codice sorgente" + "codice di test unitario" non ti dice chi / quando / perché.

Does the existence of commit history make one complacent about the long-term documentation of important information about the project, such as the major design/requirement changes and the streams of thought that drove those changes?

Suppongo che tu possa dire che lo fa. Ma pochi sviluppatori documentano accuratamente le modifiche ai requisiti / design. E certamente quasi nessuno registra il flusso di pensiero che ha guidato lo sviluppo iniziale, o le successive modifiche. Avere la cronologia del commit (e in particolare i messaggi del registro di commit) e i collegamenti incrociati al sistema di tracciamento di errori / bug forniscono almeno qualcosa da cui andare. E questo è meglio di niente, o una serie di istantanee di rilascio.

    
risposta data 24.01.2011 - 07:21
fonte

Leggi altre domande sui tag

Di quali problemi dovrei essere a conoscenza quando concedo in franchising il mio codice? Qual è la ragione per inserire prefissi nelle nuove funzionalità CSS?