Quando iniziare a utilizzare il controllo del codice sorgente nelle prime fasi di sviluppo?

Question

abbiamo 2 tipi di persone al mio negozio:

1. Quelli che inizia il check-in codice dal momento che la prima compilation di successo.
2. Gli altri che controllano solo il codice quando il progetto è quasi terminato.

Sono parte del gruppo 1 e sto cercando di convincere le persone del gruppo 2 a comportarsi come me. I loro argomenti sono i seguenti:

1. Sono lo sviluppatore solista di questo progetto.
2. È solo un prototipo, forse dovrò riscrivere da capo.
3. Non voglio inquinare il controllo del codice sorgente con versioni incomplete.

Se ho ragione, per favore aiutami a sollevare argomenti per convincerli. Se sei d'accordo con loro dimmi perché.

Answer 1

Provo a scrivere solo il codice che compila (tutto il resto è commentato con un tag TODO/FIXME) ... e aggiungo anche tutto per il controllo del codice sorgente.

Argomento 1: Anche come una singola dev è bello tornare ad una versione in esecuzione, per tenere traccia dei progressi, ecc

Argomento 2: Chi se ne frega se è solo un prototipo? Si potrebbe incappare in un problema simile in sei mesi o giù di lì, e quindi basta iniziare a cercare questo altro codice ...

Argomento 3: Perché non utilizzare più di un repo? Mi piace archiviare materiale vario nel mio repository personale.

Answer 2

Se sono l'unico sviluppatore di un progetto (in altre parole, il repository, o parte di esso, è sotto il mio controllo completo), quindi inizio a commettere il codice sorgente non appena viene scritto, e tendo a effettuare il check-in dopo ogni modifica incrementale, indipendentemente dal fatto che funzioni o rappresenti un qualsiasi tipo di traguardo.

Se sto lavorando in un repository su un progetto con gli altri, quindi tendo a cercare di fare le mie commit in modo tale che non si rompono lo sviluppo mainline, superare tutte le prove, ecc

O non è un prototipo, merita di entrare nel controllo del codice sorgente; i prototipi rappresentano un sacco di lavoro e le lezioni apprese da loro sono preziose. Inoltre, i prototipi hanno un'abitudine terribile di diventare un codice di produzione, che ti servirà nel controllo del codice sorgente.

Answer 3

Direi che dovresti iniziare ad aggiungere la fonte e controllare prima del che puoi anche costruire la prima volta. È quindi molto più semplice evitare di controllare gli artefatti generati. Uso sempre un certo controllo del codice sorgente, anche per i miei piccoli hack da hobby, solo perché filtra automaticamente il relativo dal rumore.

Così quando inizio la prototipazione potrei creare un progetto e poi prima di costruirlo faccio "git init, git add., Git commit -a -m ..." solo così quando voglio spostare le parti interessanti Ho solo clonato sull'uso di git e poi posso aggiungerlo al repository di subversion o qualunque cosa venga usata dove sto lavorando al momento.

Answer 4

Inizia a utilizzare il controllo del codice sorgente circa 20 minuti prima di scrivere la prima riga del tuo primo artefatto. Non c'è mai un buon momento per iniziare a dopo il hai iniziato a scrivere cose.

Answer 5

alcune persone possono solo imparare dall'esperienza.

come un guasto del disco rigido. o codifica se stessi in un vicolo cieco dopo l'eliminazione di codice che effettivamente lavorate

Ora, io sono non dicendo che si dovrebbe cancellare il loro disco rigido e poi li provocazione con "se il controllo di origine solo avessi usato" .. .ma se qualcosa dovesse succedere, spero che ci sia un backup fatto prima ;-)

Answer 6

Creo una directory nel controllo del codice sorgente prima di iniziare a scrivere il codice per un progetto. Faccio il primo commit dopo aver creato lo scheletro del progetto.

Answer 7

Quando qualcuno ha richiesto good excuses not to use version control, ha ottenuto 75 risposte e 45 voti positivi.

E quando hanno chiesto Why should my team adopt source control, hanno ottenuto 26 risposte.

Forse troverai qualcosa di utile lì.

Answer 8

Ecco i miei punti di vista.

1) Persino gli sviluppatori solisti hanno bisogno di un posto dove conservare il proprio codice quando il PC non funziona. Cosa succede se eliminano accidentalmente un file senza il controllo del codice sorgente?

2/3) I prototipi appartengono al controllo del codice sorgente in modo che gli altri membri del team possano visualizzare il codice. Abbiamo inserito il nostro codice prototipo in una posizione separata sul ramo principale. Lo chiamiamo Spike. Ecco un ottimo articolo sul motivo per cui dovresti mantenere il codice Spike- http://odetocode.com/Blogs/scott/archive/2008/11/17/12344.aspx

Answer 9

Presto e spesso. Come dicono i programmatori pragmatici, il controllo del codice sorgente è come una macchina del tempo e non si sa mai quando si vorrà tornare indietro.

Answer 10

Non hai bisogno di "argomenti per convincerli". Il discorso non è un gioco e non devi usare il tuo lavoro come piattaforma di dibattito. Questo è ciò che il tuo coniuge è per :) Seriamente, però, devi spiegare perché ti interessi come gli altri sviluppatori lavorano su progetti solisti in cui altre persone non sono coinvolte. Cosa manca perché non usano il controllo del codice sorgente? Hai bisogno di vedere le loro prime idee per capire il loro codice successivo? Se riesci a farlo con successo, potresti essere in grado di convincerli.

Io personalmente uso il controllo della versione in ogni momento, ma solo perché non cammino sul filo del rasoio senza rete. Altre persone hanno più coraggio, meno tempo da dedicare alle infrastrutture, ecc. Si noti che nel 2009, a mio parere, gli hard disk raramente falliscono e il codice riscritto è spesso migliore del codice che sostituisce.

Mentre sto rispondendo a una domanda con una domanda, permettetemi di chiederne un'altra: il vostro codice deve compilare/work/not-break-the-build per essere controllato? Mi piacciono i miei rami per essere buoni e rotti, quindi risolti, funzionanti, debugati, ecc. Allo stesso tempo, mi piacciono gli altri sviluppatori che usano il controllo del codice sorgente come vogliono. I rami sono stati inventati proprio per questo motivo: così le persone che non possono andare d'accordo non devono convivere.

Answer 11

Per me, si tratta di un processo coerente. Se stai scrivendo il codice, dovrebbe seguire lo stesso processo di controllo del codice sorgente del tuo codice di produzione. Ciò aiuta a costruire e applicare buone pratiche di sviluppo all'interno del team di sviluppo.

La classificazione del codice come prototipo o altro tipo di progetto non di produzione deve essere utilizzata per determinare la posizione dell'albero di controllo del codice sorgente.

Utilizziamo sia CVS (per progetti non .NET) e TFS (per progetti .NET) in cui lavoro, e il repository TFS ha una cartella Sandbox per sviluppatori in cui gli sviluppatori possono controllare progetti sperimentali personali (prototipi).

Se e quando un progetto inizia ad essere utilizzato in produzione, il codice viene spostato fuori dalla cartella Sandbox Developer nella propria cartella nell'albero principale.

Answer 12

direi a loro ...

Sono lo sviluppatore solista di questo progetto.

E quando si esce o consegnare fuori avremo 0 sviluppatori. Un motivo in più per utilizzare il controllo del codice sorgente.

Il codice appartiene alla società, non tu e la società vorrebbero una certa responsabilità. Il check-in codice non richiede troppo sforzo:

svn ci <files> -m " implement ajax support for grid control 

prossima volta che qualcuno nuovi vuole fare alcuni cambiamenti sul controllo griglia o fanno qualcosa legato, avranno un ottimo punto di partenza. Tutti i progetti iniziano con una o due persone. Il controllo del codice sorgente è più semplice di quanto non sia mai stato: hanno organizzato una demo di 30 minuti di Tortoise SVN con loro?

È solo un prototipo, forse dovrò riscrivere da capo.

Sono preoccupati per lo spazio di archiviazione? Lo stoccaggio è economico. Sono preoccupati per il tempo sprecato per il controllo delle versioni? Richiede meno tempo rispetto ai controlli e-mail rapidi. Se stanno riscrivendo i bit, il controllo del codice sorgente è ancora più importante per poter fare riferimento a vecchi bit.

Non voglio inquinare il controllo del codice sorgente con versioni incomplete.

Questa è effettivamente una buona preoccupazione. Ero solito pensare la stessa cosa a un certo punto e ho evitato di controllare il codice finché non era bello e pulito, il che non è una cosa negativa in sé e per sé, ma molte volte volevo semplicemente scherzare. A questo punto, imparare a ramificare aiuta. Anche se spero che SVN abbia pieno supporto per l'eliminazione di cartelle come Perforce.

Answer 13

Vediamo i loro argomenti:

1. Sono lo sviluppatore solista di questo progetto.
2. È solo un prototipo, forse dovrò riscrivere da capo.
3. Non voglio inquinare il controllo del codice sorgente con versioni incomplete.

Primo, il terzo.Riesco a vedere il ragionamento, ma si basa su una cattiva ipotesi.
Al lavoro, utilizziamo Perforce, un VCS centralizzato, e in effetti controlliamo solo la fonte che viene compilata correttamente e non rompere nulla (in teoria, ovviamente!), Dopo la revisione tra pari.

Così quando inizio un cambiamento non banale, sento il bisogno di commit intermedi. Ad esempio, recentemente ho iniziato a fare alcune modifiche (in qualche modo, in solo per questa particolare attività, quindi mi rivolgo al punto 1) su un codice Java usando JDom (analisi XML). Quindi sono rimasto bloccato e volevo utilizzare l'analisi XML integrata in Java 1.6. Era ovviamente il momento di tenere traccia del lavoro corrente, nel caso in cui il mio tentativo fosse fallito e volessi tornare indietro. Nota questo caso in qualche modo indirizza il punto 2.

La soluzione che ho scelto è semplice: io uso un SCM alternativo! Sebbene alcuni VCS centralizzati come SVN siano utilizzabili in locale (sul computer dello sviluppatore), sono stato sedotto dal VCS distribuito e dopo aver testato brevemente Mercurial (che è buono), ho trovato Bazaar più adatto alle mie esigenze e ai miei gusti.
DVCS sono adatti per questa attività perché sono leggeri, flessibili, consentono rami alternativi, non "inquinano" la directory di origine (tutti i dati si trovano in una directory nella radice del progetto), ecc.
Effettuando una gestione parallela delle fonti, non inquini la fonte di altri sviluppatori, pur mantenendo la possibilità di tornare indietro o provare rapidamente soluzioni alternative.

Alla fine, confermando la versione finale a SCM ufficiale, il risultato è lo stesso, ma con maggiore sicurezza a livello dello sviluppatore.

Answer 14

Vorrei aggiungere due cose. Con il controllo di versione è possibile:

• Ripristina ultima versione che ha lavorato, o almeno verificare come sembrava. Per questo è necessario SCM che supporta i changeset/usa commit di interi alberi.
• Usalo per trovare i bug, utilizzando il cosiddetto 'debugging differenziale' trovando il commit nella cronologia che ha introdotto il bug. Vorresti SCM che lo supporti in modo automatico o semi-automatico.

Answer 15

Personalmente, avvio spesso il controllo della versione dopo la prima compilazione riuscita.

Mi chiedo solo perché nessuno ha menzionato distribuito sistemi di controllo versione, in questo contesto: Se si potesse riuscire a passare ad un sistema distribuito (git, bazar, mercurio), la maggior parte degli argomenti del tuo secondo gruppo sarebbe diventato inutile dal momento che può solo avvia il loro repository localmente e lo invia al server quando lo desidera (e può anche solo rimuoverlo, se vuole ripartire da zero).

Answer 16

Si chiama branching persone cercano di ottenere con il programma: p Prototipazione? Lavora in una filiale. La sperimentazione? Lavora in una filiale. Nuova caratteristica? Lavora in una filiale.

Unisci i tuoi rami nel bagagliaio principale quando ha senso.

Answer 17

Immagino che le persone tendono ad essere rilassate quando si tratta di impostare il controllo del codice sorgente inizialmente se il codice non può mai essere utilizzato. Ho progetti che ho codificato appartenenti a entrambi i gruppi e quelli al di fuori del controllo del codice sorgente non sono meno importanti. È una di quelle cose che viene rimandata ogni giorno quando in realtà non dovrebbe.

D'altra parte a volte commetto troppo raramente complicando un ripristino una volta che ho rovinato un po 'di codice CSS e non sapendo cosa ho cambiato, ad es. per fare in modo che il piè di pagina del sito finisca dietro l'intestazione.

Answer 18

I check-in del progetto nel controllo del codice sorgente prima di iniziare la codifica. La prima cosa che faccio è creare e organizzare i progetti e supportare i file (come i file .sln nello sviluppo .NET) con le librerie e gli strumenti di supporto necessari (di solito in una cartella lib) che so che userò nel mio progetto. Se ho già scritto del codice, lo aggiungo anche se è un'applicazione incompleta. Poi faccio il check-in di tutto. Da lì, tutto è come al solito, scrivere un po 'di codice, compilarlo, testarlo, registrarlo ...

Probabilmente non avrai bisogno di diramarti da questo punto o di ripristinare le tue modifiche, ma penso che sia una buona pratica per avere tutto sotto controllo del codice sorgente fin dall'inizio, anche se non si ha nulla da compilare.

Answer 19

Sono ubriaco e, prima faccio git -init e poi vim foo.cpp.

Answer 20

Qualsiasi piattaforma di controllo della sorgente moderna decente (di cui VSS non è una sola) non dovrebbe in alcun modo essere inquinata inserendo file di codice sorgente in essa. Sono dell'opinione che tutto ciò che ha un'aspettativa di vita superiore a circa mezz'ora dovrebbe essere nel controllo della fonte il prima possibile. Lo sviluppo personale non è più una scusa valida per non utilizzare il controllo del codice sorgente. Non si tratta di sicurezza, ma di bug e di cronologia a lungo termine.