Controllo del codice "commentato" [chiuso]

Ok, ecco qualcosa che ha causato qualche attrito nel mio lavoro attuale e davvero non me l'aspettavo. Lo sviluppo di software organizzato internamente è un nuovo concetto qui e ho redatto una prima bozza di alcune linee guida di codifica.

Ho proposto che il codice "commentato" non debba mai essere archiviato nel repository. Il motivo per cui ho affermato questo è che il repository mantiene una cronologia completa dei file. Se stai rimuovendo il codice funzionale, rimuovilo del tutto. Il repository conserva le modifiche in modo che sia facile vedere cosa è stato modificato.

Ciò ha causato qualche attrito in quanto un altro sviluppatore ritiene che prendere questa strada sia troppo restrittiva. Questo sviluppatore vorrebbe essere in grado di commentare un codice su cui sta lavorando ma è incompleto. Questo codice quindi non sarebbe mai stato archiviato prima e quindi non sarebbe stato salvato da nessuna parte. Useremo TFS, quindi ho suggerito che accantonare le modifiche sarebbe la soluzione più corretta. Tuttavia, non è stato accettato perché vorrebbe essere in grado di archiviare modifiche parziali che possono essere implementate o meno.

Vogliamo finalmente arrivare a un punto in cui stiamo sfruttando appieno l'integrazione continua e distribuiamo automaticamente su un server web di sviluppo. Al momento non esiste una versione di sviluppo di server web o server di database, ma tutto sarà presto cambiato.

Comunque, cosa ne pensi? Credi che il codice "commentato" sia utile da avere nel repository?

Sono molto interessato a sentire altri su questo argomento.

Modifica: per motivi di chiarezza, non utilizziamo rami privati. Se lo facessimo, direi di fare quello che vuoi con il tuo ramo privato, ma non unire mai il codice commentato con il tronco o qualsiasi ramo condiviso.

Modifica: non esiste un motivo valido per cui non utilizziamo rami privati ​​o per utente. Non è un concetto con cui non sono d'accordo. Non l'abbiamo ancora impostato in questo modo. Forse questa è l'eventuale via di mezzo. Per ora utilizziamo scaffalature TFS.

Potrebbero esserci altri con esperienze diverse, ma nella mia controllare il codice finito a metà è un'idea orribile, punto.

Ecco i principi che ho imparato e cerco di seguire:

• Effettua il check-in spesso, almeno una volta, ma preferibilmente più volte al giorno
• Controlla solo la funzionalità completa
• Se il primo e il secondo conflitto (ad es. Ci vuole più di un giorno per far funzionare la funzionalità) allora l'attività è troppo grande, suddividila in attività più piccole completabili.

Questo significa:

• Il codice commentato non dovrebbe mai essere archiviato poiché non funziona
• Commentare non è una strategia di archiviazione valida, quindi che si tratti di codice ancora da completare o codice che viene ritirato, commentare e fare il check-in non ha alcun senso.

Quindi, in sintesi, NO! Se il codice non è pronto per passare alla fase successiva (a seconda di quale sia per te: IntTest / QA / UAT / PreProd / Prod), non dovrebbe essere eseguito il commit in un trunk o ramo multi-sviluppatore. Periodo.

Modifica: dopo aver letto le altre risposte e commenti, aggiungerò che non penso sia necessariamente una buona idea vietare il codice commentato (non sono sicuro di come lo applicheresti comunque). Quello che dirò è che dovresti fare in modo che tutti i membri del tuo team aderiscano alla filosofia che ho descritto sopra. Il team su cui lavoro lo abbraccia con tutto il cuore. Di conseguenza, il controllo del codice sorgente è un membro del team senza problemi, che ci aiuta a portare a termine il nostro lavoro.

Le persone che non abbracciano questa filosofia di solito causano finestre rotte e sono spesso frustrate dal controllo del codice sorgente. Lo vedono come un male necessario nel migliore dei casi e qualcosa da evitare nel peggiore dei casi; il che porta a check-in poco frequenti, il che significa che i changeset sono enormi e difficili da unire, il che aumenta la frustrazione, rende i check-in qualcosa da evitare ancora di più, ecc. Questa è in definitiva una cosa di atteggiamento, non realmente una cosa di processo. È facile innalzare barriere mentali contro di essa; è facile trovare ragioni per cui non funziona, così come è facile trovare ragioni per non mettersi a dieta se non lo si vuole veramente. Ma quando la gente non vuole farlo e si sono impegnati a cambiare le loro abitudini, i risultati sono drammatici. Spetta a te venderlo in modo efficace.

"Mai" è raramente una buona parola da utilizzare nelle linee guida.

Il tuo collega ha un ottimo esempio di quando potrebbe essere appropriato archiviare il codice che è commentato: quando è incompleto e potrebbe interrompere l'applicazione se archiviato mentre è attivo.

Per la maggior parte, commentare il codice morto non è necessario in un sistema ben gestito e controllato dalle modifiche. Ma non tutto il codice commentato è "morto".

Il codice commentato non dovrebbe mai essere archiviato allo scopo di mantenere la cronologia. Questo è il punto di controllo del codice sorgente.

La gente qui parla molto di ideali. Forse a differenza di tutti gli altri, devo lavorare su più progetti con più interruzioni con il "mondo reale" che occasionalmente ha interrotto la mia giornata lavorativa.

A volte, la realtà è che devo fare il check-in per completare parzialmente il codice. Si rischia di perdere il codice o di archiviare il codice incompleto. Non posso sempre permettermi di "finire" un compito, non importa quanto piccolo. Ma non scollegherò il mio laptop dalla rete senza aver effettuato il check-in di tutto il codice.

Se necessario, creerò il mio ramo di lavoro per eseguire il commit delle modifiche parziali.

Un caso in cui lascio il codice commentato:

// This approach doesn't work
// Blah, blah, blah

quando questo è l'approccio ovvio al problema ma contiene qualche sottile difetto. Certo, il repository lo avrebbe, ma il repository non avviserebbe nessuno in futuro di non seguire quella strada.

Certamente scoraggerei, fortemente, il controllo del codice commentato. Tuttavia, non lo vieterei assolutamente. A volte (se raramente) è appropriato controllare il codice commentato nel controllo del codice sorgente. Dire "non farlo mai" è troppo restrittivo.

Penso che siamo tutti d'accordo con questi punti:

• Non controllare mai il codice morto nel controllo del codice sorgente
• Non controllare mai il codice rotto (non funzionante) nel controllo del codice sorgente, almeno mai nel trunk e solo molto raramente in un ramo privato, YMMV
• Se hai temporaneamente commentato qualcosa o rotto qualcosa per scopi di debug, non archiviare il codice fino a quando non ripristini il codice nella sua forma corretta

Alcuni dicono che ci sono altre categorie, ad esempio temporaneamente codice rimosso o un miglioramento incrementale ma incompleto che include una piccola quantità di codice commentato come documentazione di ciò che viene dopo, o uno snippet molto breve (idealmente di 1 riga) di commenti fuori codice che mostra qualcosa che non dovrebbe mai essere aggiunto nuovamente. Il codice commentato dovrebbe SEMPRE essere accompagnato da un commento che spieghi perché è stato commentato (e non solo cancellato) e fornisce la durata prevista del codice commentato. Ad esempio, "Il codice seguente fa più male che bene, quindi è commentato, ma deve essere sostituito prima del rilascio XXX."

Un commento come quello sopra è appropriato se stai fornendo un hotfix per fermare l'emorragia di un cliente e non hai l'opportunità immediata di trovare la soluzione definitiva. Dopo aver consegnato l'hotfix, il codice commentato è un promemoria che hai ancora qualcosa che deve essere risolto.

Quando faccio il check-in del codice commentato? Un esempio è quando rimuovo provvisoriamente qualcosa che penso ci sia un'alta probabilità che debba essere aggiunto di nuovo nel prossimo futuro, in qualche forma. Il codice commentato serve come promemoria diretto che questo è incompleto. Certo, la vecchia versione è nel controllo del codice sorgente e potresti semplicemente usare un commento FIXME come indicatore del fatto che è necessario qualcosa di più. Tuttavia, a volte (se non spesso) il codice è il commento migliore.

Inoltre, quando un bug viene corretto rimuovendo una riga (o più raramente due righe) di codice, a volte commenterò semplicemente la riga con un commento per non riattivare mai quel codice con un motivo. Questo tipo di commento è chiaro, diretto e conciso.

Rex M ha detto: 1) Controlla solo la funzionalità completa, 2) [Se] l'attività è troppo grande, suddividila in attività più piccole completabili.

In risposta: Sì, questo è l'ideale. A volte nessuna delle opzioni è realizzabile quando si lavora sul codice di produzione e si ha un problema critico e immediato da risolvere. A volte per completare un'attività, è necessario inserire una versione del codice nel campo per un po '. Ciò è particolarmente vero per le modifiche al codice di raccolta dati quando si cerca di trovare la causa principale di un problema.

Per l'istanza specifica richiesta nella domanda più generale ... fintanto che lo sviluppatore sta controllando il codice commentato in un ramo privato che nessuno vedrà tranne quello sviluppatore (e forse qualcuno con cui lo sviluppatore sta collaborando), fa poco male. Ma quello sviluppatore non dovrebbe (quasi) mai fornire tale codice nel trunk o in un equivalente. Il tronco dovrebbe essere sempre costruito e dovrebbe funzionare sempre. Fornire codice incompleto a trunk è quasi sempre una pessima idea. Se permetti a uno sviluppatore di controllare il codice non finito o temporaneo in un ramo privato, devi fare affidamento sullo sviluppatore per non dimenticare di pulire il codice prima di consegnarlo nel trunk.

Per chiarire in risposta ai commenti ad altre risposte, se il codice viene commentato e archiviato, la mia aspettativa che il codice funzioni se non commentato diminuisce con il tempo in cui il codice è stato commentato. Ovviamente, gli strumenti di refactoring non includeranno sempre commenti nel loro refactoring. Quasi sempre, se metto in produzione del codice commentato, il codice serve come commento raffinato, qualcosa di più specifico della prosa, che qualcosa deve essere fatto lì. Non è qualcosa che dovrebbe avere una lunga vita.

Infine, se riesci a trovare codice commentato in ogni file sorgente, allora qualcosa non va. Fornire codice commentato nel trunk per qualsiasi motivo dovrebbe essere un evento raro. Se ciò si verifica spesso, diventa confuso e perde il suo valore.

Penso che non sia mai una condizione troppo forte.

Tendo a commentare, archiviare, eseguire i test, riflettere e quindi rimuovere i commenti dopo il rilascio successivo.

In generale, il check-in del codice commentato è sbagliato in quanto crea confusione tra coloro che non sono l'autore originale e hanno bisogno di leggere o modificare il codice. In ogni caso, l'autore originale finisce spesso per confondersi sul codice dopo che sono trascorsi 3 mesi.

Condivido la convinzione che il codice appartenga all'azienda o al team e che sia tua responsabilità rendere le cose facili per i tuoi colleghi. Controllare il codice commentato senza aggiungere anche un commento sul motivo per cui è stato mantenuto equivale a dire:

Non mi importa se finisci per essere confuso sul perché questa roba è qui. Le mie esigenze sono più importanti delle tue, motivo per cui l'ho fatto. Non sento alcun bisogno di giustificare a te, né a nessun altro, perché l'ho fatto.

Per me il codice commentato è normalmente visto come un segno di mancanza di rispetto da parte di un collega meno premuroso.

Sono ampiamente d'accordo con il principio che il codice commentato non dovrebbe essere archiviato. Il sistema di controllo del codice sorgente è una risorsa condivisa e il tuo collega lo utilizza, in una certa misura, come suo blocco appunti personale. Questo non è molto premuroso per gli altri utenti, specialmente se ti iscrivi all'idea della proprietà condivisa del codice base.

Il prossimo sviluppatore a vedere quel codice commentato non avrebbe idea che si tratta di un lavoro in corso. È libero di cambiarlo? È codice morto? Non lo sa.

Se il cambiamento del tuo collega non è in uno stato in cui può essere archiviato, deve completarlo e / o imparare ad apportare modifiche minori e incrementali.

"Controllo delle modifiche parziali che possono o non possono essere implementate" - presumibilmente questo significa anche che possono o non possono essere testate? È un pendio scivoloso per una base di codice molto complicata.

Quando devi aggiungere una piccola funzionalità o una correzione di bug come ADESSO, entro i prossimi 3 minuti e devi correggere un file su cui hai un codice sviluppato a metà, direi che è ok, le esigenze pratiche dominano gli ideali pragmatici sul campo di battaglia.

Ciò mostra una differenza fondamentale in due scuole di pensiero: coloro che controllano solo il codice funzionante di cui sono soddisfatti e si sentono meritevoli di salvataggio, e coloro che controllano il loro lavoro in modo che il controllo di revisione sia lì per proteggerli dalla perdita di dati.

Definirei questi ultimi come "quelli a cui piace usare il loro sistema di controllo delle revisioni come un backup su nastro dei poveri", ma questo mi darebbe una mancia sul campo in cui mi trovo. :-)

La mia ipotesi è che tu appartenga al campo del "codice buono" e lui del campo del "codice funzionante".

[MODIFICARE]

Dai commenti, sì, ho indovinato.

Come ho detto, sono con te, ma per quanto posso dire questa è un'opinione di minoranza, sia qui su StackOverflow che dove lavoro. In quanto tale, non credo che tu possa davvero inserirla nei tuoi standard di sviluppo come l'unico modo per operare. Non se vuoi che gli standard vengano comunque seguiti. Una cosa che un buon leader sa è di non dare mai un ordine che sa non sarà seguito.

btw: buoni editor aiuteranno a mantenere le vecchie versioni. Ad esempio, in Emacs ho impostato le versioni mantenute vecchie e vecchie versioni su 10, il che prevede che mantenga circa gli ultimi 10 salvataggi dei miei file. Potresti considerare questo come un modo per aiutare la tua argomentazione contro la folla del controllo di revisione come backup. Tuttavia, non vincerai mai la discussione.

Nella mia esperienza, gli switch degli sviluppatori sono codice commentato.

A volte, nuovi back-end vengono costruiti in parallelo, con gli interruttori di attivazione commentati nel controllo del codice sorgente.

Alcune caratteristiche bizzarre di cui abbiamo bisogno una volta su una luna blu, ma che nessun cliente avrà mai bisogno, viene spesso implementata in questo modo. Queste cose di solito comportano un alto rischio di bypass della sicurezza o dell'integrità dei dati, quindi non vogliamo che siano attive al di fuori dello sviluppo. Richiedere uno sviluppatore che lo utilizzi per rimuovere il commento dal codice sembra essere il modo più semplice per ottenerlo.

Un altro motivo per il check-in del codice commentato:

Stai modificando il codice esistente e hai trovato un bug sottile, facile da trascurare e forse potrebbe anche sembrare corretto a prima vista. Commentalo, metti la correzione al suo posto e aggiungi commenti su cosa sta succedendo e perché è stata modificata. Effettua il check-in, in modo che i tuoi commenti sulla correzione siano nel repository.

Forse la vera domanda qui è se gli sviluppatori dovrebbero essere autorizzati a controllare il codice incompleto?

Questa pratica sembrerebbe essere in contraddizione con l'obiettivo dichiarato di implementare l'integrazione continua.

Dipende. Se viene lasciato lì a scopo illustrativo, forse. Potrebbe essere utile durante il refactoring. Altrimenti, e in generale, no. Inoltre, commentare il codice non finito è destinato ad essere sia soggetto a errori che a perdere tempo. È meglio che divida il codice in parti più piccole e le controlli quando funzionano.

La mia opinione: se gli sviluppatori stanno lavorando sui propri rami, o nella propria area sandbox, dovrebbero essere in grado di controllare ciò che vogliono. È quando controllano il codice in un ramo condiviso (un ramo di funzionalità, o un ramo di un team, o ovviamente MAIN / trunk) che il codice dovrebbe essere il più puro possibile (nessun codice commentato, niente più FIXME, ecc.).

Penso che "Mai" sia una regola troppo forte. Voterei per lasciare un margine di manovra personale sul fatto che le persone controllino il codice commentato nel repository. L'obiettivo finale dovrebbe essere la produttività del programmatore, non "un repository incontaminato".

Per bilanciare questo lassismo, assicurati che tutti sappiano che il codice commentato ha una data di scadenza. Chiunque può eliminare il codice commentato se è in circolazione da un'intera settimana e non è mai stato attivo. (Sostituisci "una settimana" con quello che ritieni giusto per te.) In questo modo, ti riservi il diritto di eliminare il disordine quando lo vedi, senza interferire troppo direttamente con lo stile personale delle persone.

Sono assolutamente d'accordo sul fatto che il codice commentato non debba essere archiviato nel repository, a questo serve il controllo del codice sorgente.

Nella mia esperienza, quando un programmatore effettua il check-in del codice commentato, è perché non è sicuro di quale sia la soluzione giusta ed è più felice di lasciare la soluzione alternativa nel sorgente nella speranza che qualcun altro prenda quella decisione.

Trovo che complichi il codice e ne renda difficile la lettura.

Non ho problemi a controllare il codice finito a metà (in modo da ottenere il vantaggio del controllo del codice sorgente) che non viene chiamato dal sistema live. Il mio problema è trovare sezioni di codice commentato senza spiegazione, il dilemma era che il codice veniva escluso.

Penso che il check-in del codice commentato in un sistema di controllo del codice sorgente dovrebbe essere fatto con estrema cautela, specialmente se i tag della lingua usati per commentare il codice sono scritti da blocchi, cioè:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Piuttosto che su una singola linea, come:

// My commented code start here
// My commented code line 1
// My commented code line 2

(hai l'idea)

Il motivo per cui dovrei usare estrema cautela è che, a seconda della tecnologia, dovresti stare molto attento allo strumento diff / merge che stai utilizzando. Con un certo sistema di controllo del codice sorgente e una certa lingua, lo strumento diff / merge può essere facilmente confuso. Il diff / merge standard di ClearCase, ad esempio, è notoriamente dannoso per l'unione di file .xml.

Se accade che le righe dei blocchi di commento non si uniscano correttamente, presto il tuo codice diventerà attivo nel sistema quando non dovrebbe esserlo. Se il codice è incompleto e interrompe la build, questo è probabilmente il meno dannoso, poiché lo individuerai immediatamente.

Ma se il codice supera la compilazione, potrebbe diventare attivo quando non dovrebbe essere presente e, dal punto di vista di CM, potrebbe essere uno scenario da incubo. Il QA generalmente verifica ciò che dovrebbe esserci, non testano il codice che non dovrebbe essere lì, quindi il tuo codice potrebbe finire in produzione prima che tu lo sappia, e nel momento in cui si sarebbe realizzato che il codice è lì quando è non dovrebbe, i costi di manutenzione si sono moltiplicati molte volte (poiché il "bug" verrà scoperto in produzione o dal cliente, il posto o il tempo peggiore in assoluto).

L'idea di consentire alla cronologia del controllo del codice sorgente di illustrare il "vecchio modo" di fare qualcosa piuttosto che commentarla e archiviarla insieme a una spiegazione è una buona idea in teoria.

Nel mondo reale, tuttavia, nessuno guarda mai la cronologia del controllo del codice sorgente sui file su cui sta lavorando a meno che non faccia parte di un processo di revisione ufficiale di qualche tipo (fatto solo periodicamente), o se qualcosa non funziona, e lo sviluppatore non riesco a capire perché.

Anche allora, guardare indietro a più di 3 versioni praticamente non accade mai.

In parte, questo è dovuto al fatto che i sistemi di controllo del codice sorgente non rendono facile questo tipo di revisione casuale. Di solito devi controllare una vecchia versione o diff contro una vecchia versione, vedi solo due versioni, e non c'è una buona visione concisa di ciò che è cambiato che possa darti un'idea a colpo d'occhio di ciò che è cambiato.

In parte, è la combinazione della natura umana e delle esigenze della squadra. Se devo aggiustare qualcosa e posso aggiustarlo in poche ore, è improbabile che trascorra un'ora a indagare sulle vecchie versioni del codice che non sono state "attive" in un mese (che, con ogni sviluppatore che controlla in spesso, significa indietro molte revisioni), a meno che non mi capiti di sapere che c'è qualcosa lì dentro (come se ricordo una discussione su come cambiare qualcosa in relazione a quello che sto facendo ora).

Se il codice viene cancellato e archiviato di nuovo, allora, a tutti gli effetti (tranne che per lo scopo limitato di un ripristino completo) cessa di esistere. Sì, è lì per scopi di backup, ma senza una persona nel ruolo di bibliotecario del codice, andrà perso.

Il mio albero di controllo del codice sorgente del mio progetto attuale risale a circa 10 settimane fa, in un team di soli 4 ingegneri e ci sono circa 200 elenchi di modifiche impegnate. So che la mia squadra non fa un lavoro così buono come dovrebbe fare il check-in non appena c'è qualcosa di solido e pronto per partire. Ciò rende piuttosto difficile fare affidamento sulla lettura della cronologia del codice per ogni parte del codice per rilevare ogni cambiamento importante.

In questo momento, sto lavorando a un progetto in modalità di sviluppo iniziale, che è molto diverso da un progetto in modalità di manutenzione. Molti degli stessi strumenti vengono utilizzati in entrambi gli ambienti, ma le esigenze differiscono notevolmente. Ad esempio, spesso c'è un'attività che richiede che due o più ingegneri lavorino a stretto contatto per costruire qualcosa (diciamo un client e un server di qualche tipo).

Se sto scrivendo il server, potrei scrivere il codice per la bozza dell'interfaccia che il client utilizzerà e controllarlo come completamente non funzionante, in modo che l'ingegnere che scrive il client possa aggiornarlo. Questo perché abbiamo la politica che dice che l'unico modo per inviare codice da un ingegnere a un altro è attraverso il sistema di controllo del codice sorgente.

Se l'attività richiederà abbastanza tempo, varrebbe la pena creare un ramo su cui forse possiamo lavorare noi due (sebbene ciò sia contro la politica della mia organizzazione: ingegneri e singoli responsabili del team non hanno le autorizzazioni necessarie per il server di controllo del codice sorgente). In definitiva, è un compromesso, motivo per cui cerchiamo di non istituire troppe politiche "sempre" o "mai".

Probabilmente risponderei a una politica del genere senza codice mai commentato dicendo che era un po 'ingenua. Ben intenzionato, forse, ma alla fine improbabile che raggiunga il suo scopo.

Anche se vedere questo post farà tornare indietro il codice che ho controllato la scorsa settimana e rimuovere la parte commentata che non era mai definitiva (sebbene abbia funzionato) e che probabilmente non sarà mai più desiderata.

Penso che il codice commentato sia considerato "spreco".

Presumo che tu stia lavorando in un ambiente di squadra. Se stai lavorando da solo, commentando il codice con un "todo" e ci tornerai, allora è diverso. Ma in un ambiente di squadra puoi tranquillamente presumere che una volta che il codice commentato è stato archiviato, è lì per rimanere e molto probabilmente causerà più dolore che soddisfazione.

Se stai facendo revisioni del codice tra pari, potrebbe rispondere alla tua domanda. Se un altro sviluppatore rivede il tuo codice e dice "perché c'è questo codice commentato che sta cercando di fare 'blah'", allora il tuo codice ha fallito la revisione del codice e non dovresti comunque controllarlo.

Il codice commentato solleverà solo domande con altri sviluppatori, quindi sprecando tempo ed energia.

Devi porre la domanda " perché " il codice è commentato. Alcuni suggerimenti:

Se stai commentando il codice perché "non sei sicuro delle regole di business", probabilmente hai un problema con "scope creep" - meglio non sporcare la tua base di codice con requisiti che "sarebbe bello avere ma non abbiamo tempo da implementare "- mantienilo pulito con codice chiaro e test su cosa c'è effettivamente.

Se stai commentando il codice perché "non sei sicuro che sia il modo migliore per farlo", fai revisionare il tuo codice! I tempi stanno cambiando, guarderai il codice che scrivi oggi tra 2 anni e penserai che sia orribile! Ma non puoi andare in giro a commentare pezzi che "sai" possono essere fatti meglio ma non riesci a trovare un modo in questo momento. Lascia che chiunque mantenga la base di codice a lungo termine determina se esiste un modo migliore: basta che il codice venga scritto, testato e funzionante e vai avanti.

Se stai commentando il codice perché "qualcosa non funziona", FISSA ! Uno scenario comune è "test non funzionanti" o "cose ​​da fare" . Se li hai, risparmierai un sacco di tempo riparandoli o semplicemente eliminandoli. Se possono essere "rotti" per un periodo di tempo, molto probabilmente possono essere rotti per sempre.

Tutti questi potenziali scenari (e quelli che non ho menzionato qui) sono tempo e fatica sprecati. Il codice commentato potrebbe sembrare un piccolo problema ma potrebbe essere un indicatore di un problema più grande nel tuo team.

I repository sono backup del codice. Se sto lavorando sul codice ma non è completo, perché non commentarlo e registrarlo alla fine della giornata. In questo modo se il mio disco rigido muore durante la notte non avrò perso alcun lavoro. Posso controllare il codice al mattino, toglierlo dal commento e andare avanti.

L'unico motivo per cui vorrei commentarlo è perché non vorrei rompere la build durante la notte.

C'è chiaramente una tensione tra 1) il check-in anticipato e 2) il mantenimento sempre in uno stato funzionante del repository. Se hai più di pochi sviluppatori, quest'ultimo avrà la precedenza crescente, perché non puoi avere uno sviluppatore che crapa su tutti gli altri per il suo flusso di lavoro personale. Detto ciò , non dovresti sottovalutare il valore della prima linea guida. Gli sviluppatori usano tutti i diversi tipi di recinzioni mentali e flussi di lavoro personalizzati sono un modo in cui i grandi sviluppatori spremono quelle X extra. In qualità di manager, il tuo lavoro non è cercare di comprendere tutte queste sfumature - in cui fallirai a meno che tu non sia un genio e tutti i tuoi sviluppatori siano idioti - ma piuttosto permetti ai tuoi sviluppatori di essere il meglio che possono essere attraverso il loro stesso processo decisionale.

Nel commento dici che non usi rami privati. La mia domanda per te è perché no? Ok, non so nulla di TFS, quindi forse ci sono buone ragioni. Tuttavia, dopo aver usato git per un anno, devo dire che un buon DVCS diffonde totalmente questa tensione. Ci sono casi in cui trovo utile commentare il codice mentre sto costruendo un sostituto, ma perderò il sonno su di esso se lo impongo ad altri. Essere in grado di ramificarsi localmente significa che posso mantenere commit significativi per il mio processo individuale senza doversi preoccupare (o persino notificare) agli sviluppatori a valle di pasticci temporanei.

Sto solo facendo eco al ritornello. Scoraggialo a tutti i costi. Rende il codice più difficile da leggere e lascia la gente a chiedersi cosa c'è di buono / cattivo in quel codice che al momento non fa nemmeno parte dell'applicazione. Puoi sempre trovare le modifiche confrontando le revisioni. Se ci fosse stato qualche intervento chirurgico importante e il codice fosse stato commentato in massa, lo sviluppatore avrebbe dovuto annotarlo nelle note di revisione su checkin / merge.

il codice incompleto / sperimentale dovrebbe essere in un ramo da sviluppare fino al completamento. la testa / tronco dovrebbe essere la linea principale che compila sempre ed è ciò che spedisce. una volta che il ramo sperimentale è completo, dovrebbe essere unito alla linea principale / principale. C'è anche uno standard IEEE (IEEE 1042) che descrive questo se hai bisogno di documentazione di supporto.

Preferirei che il codice eventualmente danneggiato e accessibile che non viene utilizzato e che è stato ancora archiviato sullo stesso codice sia completamente non disponibile. Poiché tutto il software di controllo della versione consente una sorta di "copia di lavoro" separata dal tronco, è davvero un'idea molto migliore usare queste funzionalità.

Il codice nuovo e non funzionante va bene nel bagagliaio, perché è nuovo. Probabilmente non rompe nulla che già funziona. Se interrompe il codice funzionante, dovrebbe semplicemente andare in un ramo, in modo che altri sviluppatori possano (se necessario) controllare quel ramo e vedere cosa è rotto.

" Scar Tissue " è quello che chiamo codice commentato. Nei giorni precedenti all'uso diffuso dei sistemi di controllo della versione, Code Monkeys lasciava il codice commentato nel file nel caso in cui fosse necessario ripristinare la funzionalità.

L'unica volta in cui è accettabile il check-in del "tessuto cicatriziale" è

1. Se hai una filiale privata e
2. Non hai tempo per compilare il codice senza errori e
3. Stai andando per una lunga vacanza e
4. Non ti fidi del tuo VCS, come se usi Visual Source Safe OPPURE .
   [MODIFICARE]
5. Hai un bug sottile che potrebbe essere reintrodotto se il codice errato non viene lasciato come promemoria. (buon punto da altre risposte).

Non ci sono quasi scuse per # 4 perché ci sono molti sistemi VCS disponibili gratuitamente e robusti in giro, Git è il miglior esempio .

Altrimenti, lascia che VCS sia il tuo archivio e distributore del codice. Se un altro sviluppatore vuole esaminare il tuo codice, inviagli un'email con i diff e lascia che applichi direttamente le cose che desidera. In ogni caso, all'unione non interessa perché o come la codifica di due file sia divergente.

Poiché è un codice, il tessuto cicatriziale può distrarre di più anche di un commento ben scritto. Per la sua stessa natura di codice, si costringe il programmatore di manutenzione a spendere cicli mentali della CPU per capire se il tessuto cicatriziale ha qualcosa a che fare con i suoi cambiamenti. Non importa se la cicatrice ha una settimana o 10 anni, lasciare il tessuto cicatriziale in codice impone un peso su coloro che devono decifrare il codice dopo le parole.

[EDIT] Aggiungerei che ci sono due scenari principali che devono essere distinti:

• sviluppo privato, codificando un progetto personale o effettuando il check-in in una filiale privata
• Sviluppo della manutenzione, in cui il codice da archiviare è destinato a essere messo in produzione.

Dì solo "NO" al tessuto cicatriziale!

Non lo so - commento sempre le righe originali prima di apportare modifiche - mi aiuta a ripristinarle se cambio idea. E sì, li controllo.

Tuttavia, rimuovo qualsiasi vecchio codice commentato dal check-in precedente.

So che potrei guardare i registri delle differenze per vedere cosa è cambiato, ma è un problema: è bello vedere le ultime modifiche proprio lì nel codice.

Un buon compromesso è scrivere un piccolo strumento che scarica i file estratti / modificati su un'unità di backup di rete. In questo modo, puoi modificare fino al contenuto del tuo cuore e fare il backup del tuo lavoro, ma non devi mai controllare il codice sperimentale o incompleto.

Penso che il check-in del codice commentato dovrebbe essere valido in quanto, solo perché la nuova modifica ha superato i test, potrebbe essere più utile vedere cosa c'era prima e vedere se la nuova modifica è davvero un miglioramento.

Se dovessi tornare indietro di diverse versioni per vedere una modifica precedente che ora porta a un calo delle prestazioni, sarebbe molto fastidioso.

A volte il codice commentato è una buona cronologia, ma inserisci le date in cui il codice è stato commentato. Successivamente, qualcuno che sta lavorando lì vicino può semplicemente eliminare il codice commentato poiché è stato dimostrato che non è necessario.

Sarebbe anche utile sapere chi ha commentato quel codice in modo che se è necessaria una motivazione, è possibile chiederglielo.

Preferisco scrivere nuove funzionalità, assicurarmi che gli unit test vengano superati, archiviarli, quindi consentire ad altri di usarli e vedere come funziona.

Se lo sviluppatore ha commentato del codice perché non è ancora completo, il modo corretto di "controllo del codice sorgente" per gestirlo sarebbe che lo sviluppatore lo tenga in un suo ramo separato, finché quel codice non è pronto per il controllo nel.

Con un DVCS (come git, bazaar o mercurial) è semplicissimo in quanto non richiede modifiche nel repository centrale. Altrimenti, forse potresti parlare di dare agli sviluppatori i propri rami sul server se stanno lavorando su caratteristiche specifiche che richiederanno loro un tempo abbastanza lungo (cioè giorni).

Non c'è niente di sbagliato nel controllare il codice commentato in alcune situazioni, è solo che questa è una situazione in cui potrebbe esserci un modo migliore per farlo, quindi lo sviluppatore può tenere traccia delle modifiche alla sua fonte anche se non è pronto per essere archiviato nel repository principale.

Chiaramente, lo sviluppatore che esegue il check-in del codice commentato dovrebbe lavorare in un ramo separato, unendo le modifiche dal ramo del tronco se necessario.

Spetta al sistema VCS assistere lo sviluppatore in questo flusso di lavoro (git è un eccellente sistema VCS che funziona molto bene con questo).