Procedure consigliate per la rimozione di codice inutilizzato

Question

Vorrei sapere quali sono le migliori pratiche per rimuovere codice inutilizzato. Personalmente sono un fan dell'eliminazione (non solo di commenti) di tutto ciò che non è attualmente in uso. Ma non sono sicuro di quanto lontano andare.

Prendi questo come esempio (anche se sono interessato alla discussione generale). Nel mio progetto ho una decina di UserControls. Per una funzionalità che in seguito è stata memorizzata, ho implementato un paio di metodi e proprietà su uno degli UserControls. Il codice aggiuntivo non è specifico della funzionalità, ma è necessario per supportarlo. Potrebbe essere potenzialmente utile in seguito.

• Devo rimuovere il codice perché non lo stiamo usando al momento, e meno codice c'è più è facile da leggere? Il problema con questo è, in che modo i futuri sviluppatori sanno che questo lavoro è già stato fatto?
• O dovrei tenerlo lì, così un altro sviluppatore può trovarlo facilmente se hanno bisogno di usarlo più tardi (non penseranno di passare attraverso il controllo del codice sorgente per vedere se qualcuno lo ha fatto e cancellato)?
• Oppure c'è un'altra opzione?

Lo stesso vale per UserControls non attualmente in uso. Dovrei rimuoverli o tenerli?

Modifica: Va da sé (o ho pensato che sarebbe) che stiamo usando il controllo del codice sorgente.

Answer 1

La prima cosa da ricordare è che tutto il codice deve essere nel controllo sorgente.

Con questo in mente, è ovvio che si desidera eliminare il codice obsoleto anziché semplicemente commentarlo. I blocchi di codice commentati di qualsiasi lunghezza sono pericolosi, per almeno due motivi:

1. C'è una tendenza a supporre che i commenti siano stati mantenuti con il resto del codice. Questo non è vero e può portare a problemi come regressioni di bug.
2. È facile perdere una parentesi graffa di chiusura non commentata (ad esempio) nel mezzo di un blocco lungo.

Il codice cancellato è ancora disponibile se è davvero necessario, ma non è più ingombrante le copie di lavoro. Se sei in realtà preoccupato della rilevabilità per il vecchio codice, puoi lasciare un commento che indica che il codice è stato rimosso e il numero di revisione necessario per trovarlo. Ad una riga, è molto meglio di quello che stava usando il blocco di codice effettivo, ed è molto più chiaro che questo codice è stato lasciato scadere e esattamente per quanto tempo è scaduto.

Answer 2

Se si utilizza un sistema di controllo del codice sorgente, l'eliminazione del codice è la mia opzione preferita.

Non si intrometterà quando si lavora con il codice corrente e si avrà sempre il codice nel repository se ne hai ancora bisogno.

Answer 3

Un pezzo di codice può avere due stati.
O è attivo, funzionante e testato, nel qual caso dovrebbe trovarsi nel controllo sorgente
Oppure è obsoleto in un modo in cui non si può immaginare che qualcuno lo voglia mai utilizzare, semplicemente perché è obsoleto. In questo caso dovrebbe essere cancellato.

Non cancellare il codice in modo che "un altro sviluppatore possa trovarlo facilmente" è un motivo perfettamente valido per mantenere attivo e compilare il codice. Non preoccuparti delle dimensioni delle tue librerie, il linker rimuove tutto ciò che non viene utilizzato.

Se si sta cancellando il codice e si desidera avvisare altri del codice che era presente e per la ragione è stato eliminato in modo che non possano ripetere lo stesso errore, è possibile inserire un buon commento.

Answer 4

Sono anche un fan dell'eliminazione del codice inutilizzato.

Se so che il codice può essere utile in seguito, ho creato un ramo prima di eliminare il codice dal trunk (stiamo usando subversion - quindi creare branch è molto economico e facile). Questo mi consente di recuperare facilmente quel codice una volta/se è necessario.

Ad esempio, se si dispone di una nuova funzione, che non sarà completata per un rilascio, questa procedura consente di rimuovere la funzione parziale dal trunk, ma sarà possibile aggiungerla nuovamente una volta terminato esso.

Answer 5

La mia ipotesi è che anche se si commenta che è nel repository, verrà riscritto al posto di qualcuno che torna indietro e lo cattura.

Non che io abbia lavorato in molti posti con questa politica "nessun codice lasciato indietro" (solo uno), ma non ho MAI visto qualcuno tornare nel repository e ottenere un vecchio codice.

Tuttavia, tranne che per piccoli blocchi, non ho mai visto nessuno scomporre il codice di qualcun altro!

Se si desidera salvarlo, lascerei completamente implementato e testato (verificare i test!) Ma in una condizione che cambierà se il nuovo codice è mai necessario.

Ho avuto il codice non necessario solo "Accendi" quando era necessario, è davvero una bella sensazione (non che si possa sempre fare).

Se non si può essere disturbati a renderlo completamente funzionale e testato, quindi tagliare e lasciare che il prossimo ragazzo riscriverlo.

Answer 6

Di solito lasciavo inattivo il codice morto per un po 'finché il suo utilizzo non si è stabilizzato & Non userò più quella funzionalità. A quel punto, lo rimuovo.

Answer 7

Abbiamo un'area "Obsoleta" nell'albero dei sorgenti in cui spostiamo elementi che non vengono più utilizzati. È lontano dal bagagliaio in un'area che normalmente non è stata controllata, quindi nessuno deve guardarla.

Answer 8

Ho intenzione di suggerire di sostituire il codice cancellato con un commento che specifica l'elemento di lavoro contro il quale il codice è stato cancellato. Il mio razionale è che questo fornisce un "gancio" sul quale possono essere allegati tutti i commenti di revisione del codice. Stiamo usando i set di modifiche TFS per fare revisioni del codice VS Professional. Se il codice è cancellato al 100% non c'è un gancio.