Devo rimuovere il codice senza riferimento?

Sto lavorando su una base di codice di medie dimensioni (100k righe), è tutto codice relativamente recente (meno di un anno di età) e ha una buona copertura dei test unitari.

Continuo a imbattermi in metodi che non sono più utilizzati da nessuna parte o sono solo citati nei test unitari che testano solo quel metodo specifico.

Devo rimuovere questo codice se sono sicuro che non è più necessario?

Motivi per rimuoverlo:

• Meno codice, meno bug
• Meno codice è più facile da digerire per gli altri
• È ancora sotto il controllo del codice sorgente

Ragioni per mantenerlo:

• Può essere usato come riferimento
• Potrebbe essere utile qualche volta
• Potrebbe essere stato scritto per "arrotondare" la funzionalità di una classe

La maggior parte dei motivi per mantenerlo sono assolutamente irrilevanti, per dirla semplicemente. Se il codice non viene utilizzato, buttalo via: qualsiasi vantaggio derivante dal mantenerlo può essere derivato banalmente dal controllo del codice sorgente. Al massimo, lascia un commento dicendo in quale revisione trovarlo.

Molto semplicemente, prima tagli il codice, prima non dovrai perdere tempo a mantenerlo, compilarlo e testarlo. Questi vantaggi superano enormemente i vantaggi banali che hai delineato, che possono comunque derivare dal controllo del codice sorgente.

Tutti i motivi per rimuoverlo sono validi.

Ragioni per mantenerlo:

• Può essere usato come riferimento
• Potrebbe essere utile qualche volta
• Potrebbe essere stato scritto per "arrotondare" la funzionalità di una classe

Tutti questi motivi per mantenerlo saranno gestiti dal controllo del codice sorgente. Rimuovilo dal codice live e sarai in grado di recuperarlo se / quando è necessario.

Il codice senza riferimento è lo stesso di mantenere quelle batterie che sono un po 'scariche, nel caso in cui ne avessi bisogno un giorno per una torcia.

Fintanto che stai usando un qualche tipo di controllo di versione, direi di eliminarlo dal codice live e utilizzare la cronologia delle versioni nel caso risultasse utile.

L'unica buona ragione che posso vedere per mantenere il codice che non è attualmente utilizzato è se fa parte di un modulo autonomo: anche se alcune parti del codice potrebbero non essere utilizzate al momento, potrebbe anche essere che saranno usato in futuro.

Questo può essere particolarmente vero per una libreria che usi in diversi progetti: non vuoi continuare a lanciare pezzi di codice dentro e fuori, in base a ciò di cui hai bisogno per un progetto specifico: trovo che questo tempo richieda e sia soggetto a errori.

Il mio approccio è: (1) se lo usi una volta, mantieni solo ciò di cui hai veramente bisogno; (2) se lo usi due volte, copialo e adattalo la seconda volta che lo usi; (3) se lo usi più di due volte, crea un modulo ben definito e stabile e usa questo modulo di cui hai bisogno.

Riassumendo: eliminerei tutto il codice inutilizzato a meno che non faccia parte di un modulo per scopi generici che hai progettato come tale e che sai di riutilizzare più volte.

Nota : naturalmente, una soluzione ancora più pulita sarebbe quella di creare un progetto separato per una libreria e aggiungere una dipendenza tra i progetti.

In generale, mi inchinerei a YAGNI su questo. Se "non ne avrai bisogno", allora sta semplicemente occupando spazio nella tua base di codice, unit test e assiemi. Potresti finire per averne bisogno, ma potresti anche finire per doverlo riscrivere completamente perché tra adesso e quando hai bisogno di qualcosa del genere, molte cose possono cambiare.

Tuttavia, ciò cambia leggermente quando si scrive un'utilità o un'API destinata al consumo generale. Proprio come non puoi mai aspettarti che gli utenti finali del software interagiscano con il software nel modo in cui intendevi, non puoi mai aspettarti che i consumatori del tuo codice vogliano usare il tuo codice esattamente come pensi che dovrebbero. In questi casi, fintanto che puoi giustificare l'esistenza di un metodo con "è un modo valido per interagire con il mio oggetto", allora dovrebbe probabilmente entrare, perché anche se non ne avrai bisogno, è probabile che QUALCUNO lo faccia .

Dato che la base di codice ha meno di un anno, è probabilmente ancora in fase di sviluppo (sì?) - quindi l'idea che alcuni bit potrebbero dover risorgere nel prossimo futuro non è irragionevole.

Per i bit che erano difficili da ottenere in primo luogo e che sembrano più probabili essere resuscitati, li terrei un po 'più "attivi" rispetto al semplice controllo del codice sorgente. La gente non saprà / ricorderà che esistono - dicendo "puoi semplicemente trovarlo nel controllo del codice sorgente" presume che tu sappia / ricordi che è lì! In questi tipi di casi, considera la deprecazione (con un "assert (false)" showstopper) o il commento.

Se il codice è banale e poco interessante, lo butto via per eliminare l'inerzia non necessaria del sistema software.

Per i cadaveri di codice interessanti, utilizzo un archiveramo nei miei sistemi di controllo della versione.

"Può essere usato come riferimento" Non vorrei essere d'accordo con l'essere un buon motivo per lasciare nel codice inutilizzato. Spesso, solo una piccola parte del codice inutilizzato sta effettivamente dimostrando qualcosa di interessante. Esistono diversi modi per documentare e archiviare codice utile ma inutilizzato.

Sebbene il controllo della versione conterrà una cronologia che ti consentirà facilmente di ripristinare particolari funzionalità se in seguito decidi che il codice è necessario, sapendo che devi andare a cercare nella cronologia del controllo di versione per trovare xy o z da chi sa quale può essere la revisione precedente un po 'noioso, e spesso viene trascurato a meno che tu non abbia un'idea abbastanza specifica di ciò che stai cercando.

Il codice potrebbe essere commentato con una nota su quando è stato rimosso e perché non è stato semplicemente eliminato dal codice. Tuttavia, questo è generalmente considerato uno stile errato e il codice che non viene utilizzato e non gestito correttamente può introdurre tutti i tipi di bug se viene decommentato in seguito, quindi è generalmente meglio come fase di debug / test temporaneo durante il refactoring intermedio rispetto a un modo per lasciare il codice di produzione.

Il mio modo preferito per memorizzare il codice cancellato, se sembra essere utile in futuro, è creare un documento di riferimento secondario contenente tutti i vari blocchi di codice cancellato utile. Ogni blocco di codice è etichettato con una breve menzione di da dove proviene o qualsiasi altra cosa pertinente da ricordare, come quando è stato rimosso o il numero di revisione in cui era l'ultimo nel codice. Tutto rimosso ma "potenzialmente utile" è in un posto, facilmente ricercabile, ma non richiede uno sforzo costante per mantenere e testare su base continuativa (che il test viene rinviato a qualunque punto del codice venga reintrodotto).

Un buon motivo per mantenere i metodi inutilizzati è: potrebbero essere usati su altri rami / tag!

Esplora tutti i rami e i tag attivi prima di rimuoverli.

Se usi un sistema di controllo della versione, non preoccuparti di riferimenti futuri, poiché puoi semplicemente consultare la cronologia di quel codice e trovare la parte eliminata. Se non lo fai e pensi che un giorno verrebbe usato, allora lascialo semplicemente lì, ma commentalo con una descrizione che spiega perché è commentato.

Tuttavia, se sei sicuro di non utilizzarlo in futuro, rimuovilo semplicemente . Penso che le ragioni che hai citato siano piuttosto semplici per la rimozione del codice.

Ma per favore prima di rimuoverlo, assicurati che non sia usato da nessuna parte. Visual Studio ha una funzione chiamata Trova tutti i riferimenti che cerca l'intera soluzione e trova qualsiasi riferimento alla variabile, al metodo, alla proprietà, alla classe, all'interfaccia attuali, ecc. Sono sempre sicuro che non sia presente alcun riferimento prima di rimuovere parte del mio codice.

Ho avuto relativamente frequentemente l'esperienza di trovare una funzione che sembra fare esattamente ciò di cui ho bisogno e di fidarmi che funzioni dal momento che è in produzione da molto tempo, solo per scoprire che non è stata effettivamente utilizzata parecchi anni. Il codice che non viene utilizzato non viene mantenuto e, sebbene possa aver funzionato anni fa, l'API tutt'intorno è cambiata abbastanza da non fidarti.

Nel migliore dei casi, finisci per passare un sacco di tempo assicurandoti che in realtà faccia ancora quello che vuoi. Nel peggiore dei casi, sembra funzionare fino a quando non sarai morso da un brutto bug in un secondo momento, e impiegherà più tempo a rintracciarlo perché hai presupposto che il codice "testato in produzione" funzioni, quindi il problema deve essere altrove nel tuo nuovo codice. Nella mia esperienza, è quasi sempre più veloce solo scrivere una nuova funzione da solo.

Se lo elimini, ma scopri abbastanza presto che in realtà ne hai bisogno, è proprio lì nel controllo del codice sorgente. Se non ti serve fino a quando non è passato così tanto tempo che non ricordi che è nel controllo del codice sorgente, probabilmente è meglio scriverlo da zero comunque.

Niente consuma meno tempo di nessun codice.

Se devi immergerti in una base di codice, hai bisogno di un po 'di tempo per capire, a cosa serve quel codice, e se non viene usato per niente, hai bisogno di ancora più tempo.

Ok - questo potrebbe essere guarito essere un commento, ma poi tutti ragioneranno sul perché questo codice inutilizzato sia ancora nella base di codice, se debba essere rimosso o meno.

Se non c'è nulla, nessuno perderà tempo con esso.

Se è stato difficile farlo bene, hai bisogno di una buona documentazione, che questo codice esiste, ma se la base di codice si evolve su alcune iterazioni, forse non funzionerà più, se viene riattivato.

Rimuovi il codice inutilizzato: meno disordine, migliore comprensione. Il tuo sistema di controllo della versione si prenderà cura di te. Inoltre, se stai usando qualcosa di meglio del blocco note, il tuo ambiente ti consentirà di utilizzare il codice più vecchio come riferimento.

I lunghi commenti del vecchio codice sono fonte di distrazione e rendono difficile la navigazione.

Saluti

Segui questo semplice algoritmo:

1. Viene eseguito il backup in un SCM? Se sì, passa al 3.
2. Imposta un SCM.
3. Butta via la roba .

Tutti i tuoi punti a favore della rimozione sono validi.

Tutti i tuoi punti a favore di mantenere il disordine non sono validi una volta che hai un SCM per cercarlo o ripristinarlo. In realtà, il tuo SCM dovrebbe essere in grado di aiutarti a determinare perché quel codice è qui e non utilizzato, se è stato usato correttamente.

Si chiama "codice morto" per un motivo. Lascia che muoia e riposa in pace.

Rimarrà nel controllo del codice sorgente; non dovrebbe rimanere nella base di codice attiva.

L'unica eccezione è se il codice completa la progettazione e mentre non lo stai utilizzando, prevedi di renderlo pubblico e altri potrebbero desiderare quella funzionalità di base. Quindi, basta progettare i test per assicurarsi che queste parti del codice funzionino e che imitino il modo in cui si propongono agli altri di utilizzare queste parti del codice. Tuttavia, se stai pensando di eliminare il codice e non riesci a trovare un motivo valido per mantenerlo, dovrebbe andare. Il codice inutilizzato rende più lavoro per tutti (più difficile da leggere il codice; il codice potrebbe essere rotto; più lavoro da mantenere; ecc.)

Nella mia esperienza, anche la rimozione di codice inutilizzato può ritorcersi contro. Potresti dimenticare di avere quel codice e non lo cercherai nella storia. Oppure potresti non sapere nemmeno che qualcuno ha implementato quel codice e poi lo ha rimosso in seguito. Ancora una volta, non lo cercherai nella storia ...

Senza dubbio, avere un codice inutilizzato è un cattivo odore.

AGGIORNAMENTO: Ho appena notato che Ed Staub ha dato una risposta molto simile.