Come si lavora in sicurezza attorno al codice rotto? [chiuso]

Questo sembra un problema di processo interno più che un problema di check-in. Dovresti lavorare con la persona per assicurarti che stia facendo test e debug appropriati per assicurarsi che il codice funzioni. Se hai un gruppo di tester, assicurati che invii loro le sue modifiche per testare, sono generalmente bravi a trovare problemi.

Potresti anche portare queste discussioni nelle riunioni - "Ehi, le modifiche al tuo codice influenzeranno in qualche modo i nostri cambiamenti?", "Come integreremo i nostri cambiamenti insieme senza problemi una volta che entrambi saranno finiti?".

Questi sono fondamentali per lavorare in gruppo.

Dovresti prendere in considerazione l'utilizzo di branch di funzionalità nel tuo repository di origine.

Considerare anche un server di integrazione continua. Aiuterà a garantire che solo il codice compilabile sia archiviato nell'albero dei sorgenti. Ancora meglio se supera i test automatici delle unità.

Hai un trucco per impedirti di effettuare il check in di modifiche indesiderate?

Prima di eseguire il commit di un file, prendi un diff della versione corrente sul genitore e ricontrolla ogni modifica per assicurarti che sia ciò che intendi commettere. Questo è anche un buon momento per analizzare i tuoi cambiamenti sul fatto che sia la soluzione migliore, se sarà difficile da mantenere per gli sviluppatori futuri, ecc.

Quando sono al punto in cui desidero eseguire il commit, di solito guardo ciascun file modificato per verificare le modifiche come descritto sopra e, mentre procedo, decidere quali file raggruppare in un singolo commit. Dopo averli controllati tutti, commetto i file come pianificato.

Questo processo richiede che ti impegni più spesso, ma spesso è una buona cosa.

Il codice errato non dovrebbe essere commesso in primo luogo. Rompere la build non è una cosa carina da fare quando si lavora in una squadra, e diversi team hanno approcci diversi per incoraggiare gli sviluppatori a controllare due volte prima di commettere il codice.

Se il codice interrompe la compilazione, non dovresti commentarlo. O vedi dove si trova il problema, quindi puoi risolverlo facilmente da solo o dovresti discutere il problema direttamente con la persona che ha commesso un codice errato. Il solo invio del codice non farà scomparire il problema. È come voltare le spalle a un mostro: non vedresti più il mostro, ma la bestia è ancora qui.

Nota anche che:

• Il codice errato è già stato eseguito. Se non vuoi che questo codice sia nella build, invece di commentarlo, cancellalo. Puoi sempre recuperare il codice dal controllo della versione; questo è il punto di averne uno.

• Il problema potrebbe venire da uno sviluppatore che di solito usa sistemi di controllo delle versioni come Git. In quei sistemi, uno può impegnarsi tutte le volte che vuole, senza intaccare il lavoro di altre persone. Una volta che il codice è stato controllato per la correttezza, viene commesso allo stato jolly, interessando l'intero team.

  Gli sviluppatori che lavorano in questo modo si perdono di solito quando si tratta di sistemi di controllo delle versioni precedenti, come SVN. Se stanno commettendo troppo spesso le loro modifiche, non possono controllare il codice per la correttezza ogni volta; allo stesso tempo, non è molto corretto obbligarli a eseguire il commit meno frequentemente.

Per rispondere (1) come su:

#ifndef DODGY_CODE_I_WANT_TO_DISABLE
.
.
// the dodgy code
.
.
#endif

Questo, ovviamente, è la sintassi C, ma simile è senza dubbio disponibile per qualunque lingua tu stia usando.

Mai (e intendo MAI) "commentare" il codice per disabilitarlo, in quanto (a) questo perderà / verrà dimenticato e si confonderà per commenti autentici, e (b) i commenti al suo interno potrebbero terminare accidentalmente il commento .

Considerando tutti gli altri consigli sulla qualità dei processi e del codice, se hai intenzione di commentare un codice rotto, metti un grande cartello lampeggiante su di esso.

// FIXME: Commented out due to broken build

Quindi, prima di effettuare il check-in, cerca FIXME e annulla queste modifiche.