È mai OK eseguire il commit di codice non funzionante?

Una delle filosofie di ramificazione (sezione Sviluppo della strategia di branchia e criteri di codifica in Strategie di ramificazione avanzata di SCM - leggi anche Perforce Best practice , è un pdf ma contiene altri dettagli) è che ci si ramifica su criteri incompatibili.

A codeline policy specifies the fair use and permissible check-ins for the codeline, and is the essential user’s manual for codeline SCM. For example, the policy of a development codeline should state that it isn’t for release; likewise, the policy of a release codeline should limit changes to approved bug fixes. The policy can also describe how to document changes being checked in, what review is needed, what testing is required, and the expectations of codeline stability after check-ins. A policy is a critical component for a documented, enforceable software development process, and a codeline without a policy, from an SCM point of view, is out of control.

(da Perforce Best Practices)

Supponiamo che tu abbia il "rilascio" dei rami (o "master") da cui è stato creato un rilascio e "trunk" (o "dev") in cui gli sviluppatori controllano il codice di lavoro. Queste sono le politiche delle filiali. Notando che il "codice di lavoro" fa parte della politica di ramo "dev", non si dovrebbe mai commettere codice spezzato sul ramo dev. Spesso ci sono cose come i server CI collegati a questi rami e il controllo del codice spezzato in dev potrebbe rovinare il ramo di tutti e interrompere la compilazione.

Tuttavia, ci sono momenti in cui è opportuno verificare il codice parziale che non funziona. In questi casi, si dovrebbe ramificare una politica incompatibile con il trunk. In questo nuovo ramo, si può decidere la politica ("codice danneggiato è ok") e quindi impegnarsi con il codice.

There is one simple rule to determine if a codeline should be branched: it should be branched when its users need different check-in policies. For example, a product release group may need a check-in policy that enforces rigorous testing, whereas a development team may need a policy that allows frequent check-ins of partially tested changes. This policy divergence calls for a codeline branch. When one development group doesn’t wish to see another

(da Perforce Best Practices)

Comprendi che questo proviene da un SCM basato su server centrale con una strong mentalità aziendale. L'idea centrale è ancora buona. Questi sono spesso considerati implicitamente - non si controlla il codice dev non testato nel ramo di rilascio. Questa è una politica.

Quindi diramati, dì che questo ramo può avere un codice rotto e commettere errori.

Una delle filosofie suggerite da Linus Torvalds è che la programmazione creativa dovrebbe essere come una serie di esperimenti. Hai un'idea e seguila. Non sempre funziona, ma almeno lo hai provato. Vuoi incoraggiare gli sviluppatori a provare idee creative e, per farlo, deve essere economico per provare quell'esperimento ed è economico da recuperare. Questo è il vero potere del commit di git essendo così economico (veloce e facile). Apre questo paradigma creativo che consente agli sviluppatori di provare cose che altrimenti potrebbero non avere. Questa è la liberazione di git.

Sì, purché non si tratti di un ramo di rilascio.

Nei rami personali, tutto va e può essere scartato se l'esperimento non ha funzionato. Questo è uno dei principali vantaggi di DVCS: freedom

Il valore di commit di codice non funzionante ?: collaboration e sperimentazione

Sì, è OK ed è qualcosa che faccio molto.

Il punto di inserire codice non compilabile (almeno nelle filiali) è che a volte il tuo codice è un work-in-progress, ma che il lavoro svolto finora vale la pena di essere salvato e / o condiviso con altri

Le mie pratiche sono:

• scrivi prima i test
I commit
• wip (work-in-progress) sono buoni
• esegue spesso commit (più volte in un giorno) e in anticipo (salva i passaggi "di lavoro")
• push dopo ogni commit (nel caso in cui i dischi rigidi si blocchino / il bus ti colpisca)
• lavora sempre dapprima nelle filiali
• quando possibile si fondono solo in codice funzionante per il master
• rebase interattivo in git per schiacciare i wips prima dell'unione master

Il problema principale e forse quello a cui si sta lavorando è quando si ha una funzionalità che funziona fondamentalmente e che è strettamente necessaria per il business (e quindi deve essere in "master") ma ha alcuni test non validi. Un'opzione qui potrebbe essere quella di fare un test in sospeso che ti permetta di andare avanti per ora. Tuttavia questo è irto di pericoli in quanto il test potrebbe non essere mai risolto e potrebbe impostare uno schema in altre aree semplicemente per "testare" i test non utilizzati invece di risolverli.

Un'altra opzione sarebbe quella di utilizzare e distribuire temporaneamente il ramo. Questo può aiutare in determinate situazioni, ma in genere non è raccomandato e non è sostenibile.

Forse l'opzione migliore è sostanzialmente quella di adottare un approccio più professionale allo sviluppo del software e richiedere realmente test di funzionamento per qualsiasi codice impegnato. Questa è spesso la parte "difficile" dello sviluppo del software, non la codifica che molte persone immaginano. Un approccio migliore richiederà probabilmente migliori stime iniziali, allocazione delle risorse, impostazione delle priorità, ecc. Inoltre, durante lo sviluppo Agile, consentendo un tempo sufficiente e una disciplina sufficiente per correggere eventuali problemi sia nel momento in cui si verificano che durante la cura - sessioni di puntamento.

Concentrati su cosa significa "fatto" - significa che il codice E i test sono scritti, sono stati rifatti e lavorati. Se senti commenti come "per lo più fatti, devi soltanto scrivere / correggere / refactare test, allora NON è fatto. Dire che una funzione viene eseguita senza che sia tecnicamente completa è uno degli errori più comuni dei programmatori junior.

Il valore di qualsiasi commit, interrotto o non, è che il codice è impegnato su un server. Negli ambienti professionali, quel server è sicuro, backup ridondanti e in esecuzione. Se lavoro tutto il giorno, il commit è un modo per assicurarmi che il mio codice sopravviva qualunque cosa accada al mio computer locale. I dischi rigidi muoiono. I computer portatili vengono persi o rubati. I backup del server di repository saranno disponibili anche se l'edificio si esaurisce.

Prima di iniziare a diventare dogmatico su come lavorare con il controllo della versione, vale la pena di pensare a perché stai lavorando con il controllo della versione.

La registrazione al controllo della versione blocca lo stato del codice per riferimenti futuri: tutto il resto viene eliminato. Guardare le differenze e creare patch è solo vedere come il codice è cambiato tra le istantanee. Rami e tag sono solo modi di organizzare le istantanee. Condividere il codice con altri sviluppatori significa semplicemente dare un'occhiata ad una particolare istantanea.

Quando dovresti impegnarti? Quando c'è una ragionevole possibilità di guardare lo stato del tuo codice (o il messaggio di commit che spiega una modifica) in futuro.

Git ti offre un sacco di flessibilità su come organizzare le tue istantanee. Non esiste un repository centrale in modo da poter condividere il codice con altri sviluppatori senza forzare lo stato nel repository "principale". Puoi facilmente creare, unire e amp; elimina i rami per isolare i dettagli di un insieme di stati dalla narrazione del codice principale. Puoi eseguire il commit localmente, per aiutarti a annullare un follow al tuo attuale sviluppo, e poi raggruppare tutto in un singolo commit prima di spingerlo fuori affinché gli altri possano vederlo. Puoi taggare le revisioni specifiche in modo che siano facili da trovare in seguito.

KISS . Quello che funziona meglio per un singolo sviluppatore nelle prime fasi di sviluppo di un piccolo progetto sarà completamente diverso da quello che devi fare quando hai un centinaio di sviluppatori che lavorano su un sistema decennale e mission-critical. In qualsiasi processo di sviluppo software, dovresti evitare di creare inutili artefatti semplicemente perché qualcun altro ti ha detto di farlo.

Pensaci in questo modo. Come sviluppatore, una delle cose più dirompenti che devi fare è impedire agli altri sviluppatori del tuo team di lavorare sulle loro attività.

La filosofia del solo utilizzo del codice di lavoro proviene da team di sviluppo che lavorano sullo stesso trunk singolo nel repository. Può sembrare follia ora, ma 10 anni fa, questo era il modo normale di lavorare. Un ramo appariva quando volevi creare una versione stabile, ma il pensiero di uno sviluppatore che lavorava in un ramo per implementare una nuova funzione era quasi sconosciuto.

Se il tuo ambiente significa che i tuoi commit non influenzano immediatamente altri sviluppatori, quindi esegui spesso commit. ti dà più sicurezza nel codice, rendendo più facile il rollback di un errore di codice e molti sistemi di controllo del codice sorgente ti danno una certa protezione del codice per il codice impegnato (anche se non tutti).

Ora, assicurati che la tua fusione con le filiali condivise con altri sviluppatori funzioni e che qualsiasi codice che promuovi a questo livello venga compilato, superi tutti i test unitari e altri controlli di integrità basati sul team ... è essenziale se non lo fai Voglio continuare a comprare la birra nel pub ...

Costruisci / Rilascia rami

Non si dovrebbe mai deliberatamente commettere codice spezzato su un ramo di build. Qualsiasi ramo che si trova in un'integrazione continua o da cui vengono create versioni o build giornaliere dovrebbe sempre trovarsi in uno stato potenzialmente rilasciabile.

Altre filiali: salva spesso lo stato

Per le filiali private o feature, gli obiettivi sono spesso diversi. Il frequente check-in del codice (che funzioni o meno) può essere desiderabile. In generale, dovrai impegnarti in qualsiasi momento per il riavvolgimento allo stato corrente.

Considera questi esempi in cui lo stato salvato offre un vantaggio significativo:

• È possibile eseguire un commit prima di eseguire una ricerca e sostituzione globali in modo da poter ripristinare la struttura in una singola operazione se le cose vanno male.
• È possibile eseguire una serie di commit provvisori durante il refactoring di una parte di codice complessa in modo da poterla bisecare o riavvolgere se si finisce per rompere qualcosa nel processo.
• Potresti eseguire un commit, avviare un nuovo ramo o creare un tag quando vuoi provare qualcosa di sperimentale, mentre puoi tornare allo stato dell'albero di lavoro corrente in qualsiasi momento.

Il commit di alcuni code-base danneggiati va bene fintanto che è locale.

Perché?

• È essenziale utilizzare l'impegno come punto di salvataggio nel tuo sviluppo
• Ti mostra un modello di pensiero usato durante lo sviluppo del prodotto.
• È che non interrompe la collaborazione .

Tuttavia, quando c'è una squadra di programmatori, la filosofia della programmazione della casa è fondamentale e sostituisce i singoli comportamenti di commit. Alcune case di programmazione decidono di registrare tutti i progressi mentre altri decidono di eseguire il commit solo del codice che risolve una funzionalità. In questo caso, il valore ( costo , dal punto di vista della gestione del software) di un commit interrotto è terribile:

Il tempo
1. utilizzato per ulteriori funzioni ora viene impiegato per correggere errori ...
2. il taglio di sviluppo non è soddisfatto ...
3. il prodotto non viene spedito nei tempi

Altri punti possono essere aggiunti a questi tre effetti a cascata in modo esponenziale nel crollo di una società ... naturalmente, questo deve essere un effetto del cronico abituale errore di codice errato.

Non penso che sia OK commettere codice non funzionante.

Che succede se

• È necessaria una correzione rapida urgente. La base del codice è in uno stato rotto. Sei costretto a eseguire il rollback, correggere e distribuire.

• Qualcun altro inizia a lavorare nello stesso ramo senza sapere che hai commesso un codice non funzionante. Potrebbero essere a caccia di una "falsa pista" pensando che i loro cambiamenti abbiano infranto qualcosa.

• Decidi di lasciare la compagnia, di andare in vacanza o di non andare al lavoro per nessun motivo. I tuoi colleghi dovranno scavare in profondità per trovare ciò che è rotto e perché è stato commesso in uno stato rotto.

• Qualcuno distribuisce il tuo "codice danneggiato"? Questo può essere un "game over" se lavori con dati personali o su un fornitore di servizi di pagamento.

Rispondi a @WarrenT

Sono d'accordo con te sul fatto che in un mondo ideale in cui tutti lavorano in un branch di funzionalità, l'utilizzo di codice non funzionante potrebbe funzionare. Ho lavorato su progetti di grandi dimensioni e anche in quel caso c'erano casi in cui più persone dovevano lavorare in un unico reparto di funzionalità. Ho anche visto persone che commettevano codice "non funzionante" nel ramo principale perché l'uscita era a settimane di distanza e avevano in programma di risolverlo il giorno successivo. Tutte queste cose sono candidate a un disastro e credo fermamente che dovrebbero essere evitate a tutti i costi.

Alcune domande per aiutarti a stabilire se è possibile eseguire il commit di codice non funzionante:

1. Sei sovraccaricato?
2. I tuoi compagni di squadra interrompono costantemente la build?
3. Il tuo codice è un pasticcio e apparentemente non può peggiorare?

Se dici di sì a uno dei precedenti, allora sì, è ok per commettere codice non funzionante.

Ricordati di risolverlo il prima possibile, coprirlo con qualsiasi test unitario applicabile e scusarti per aver distrutto la build.