Come si elimina in modo sicuro un pezzo di codice che sembra non sia mai stato inserito?

Nel mio mondo fantasy perfetto in cui ho una copertura del 100% del test unitario, lo eliminerei, eseguirò i miei test unitari e quando nessun test diventa rosso, lo commetto.

Ma sfortunatamente devo svegliarmi ogni mattina e affrontare la dura realtà in cui un sacco di codice non ha test unitari o quando ci sono non ci si può fidare per coprire davvero ogni caso limite. Quindi considererei il rischio / la ricompensa e giungere alla conclusione che semplicemente non ne vale la pena:

• Premio: il codice è un po 'più facile da mantenere in futuro.
• Rischio: spezzare il codice in qualche caso oscuro a cui non stavo pensando, causare un incidente quando meno me lo aspetto, ed essere in colpa per questo perché dovevo soddisfare il mio OCD di qualità del codice e fare un cambiamento senza valore di business percepibile a qualsiasi stakeholder che non sia un programmatore stesso.

Ci sono due metà di questo processo. Il primo sta confermando che il codice è davvero morto. Il secondo è comprendere i costi dell'errore e assicurarsi che siano adeguatamente mitigati.

Molte risposte qui hanno ottime soluzioni per la metà precedente. Strumenti come analizzatori statici sono ottimi per identificare il codice morto. grep può essere tuo amico in alcuni casi. Un passo insolito che prendo spesso è cercare di identificare quale fosse lo scopo originale del codice. È molto più facile sostenere che "X non è più una caratteristica del nostro prodotto e il segmento di codice Y è stato progettato per supportare la caratteristica X" piuttosto che "Non vedo alcuno scopo per il segmento di codice Y".

La seconda parte è un passo fondamentale per superare qualsiasi blocco di griglia sul fatto che sia necessario rimuovere il codice. Hai bisogno di capire quali sono le implicazioni di ottenere la risposta sbagliata. Se le persone moriranno se si ottiene la risposta sbagliata, prestare attenzione! Forse è un buon momento per accettare che il codice cruft si sviluppi nel tempo e invece cerca di non scrivere più da solo. Se le persone non moriranno, chiediti come perdonare i tuoi utenti. Puoi inviare loro un hotfix se hai rotto qualcosa e mantenere i rapporti con i clienti? Hai un team di Q & A pagato per trovare problemi come questo? Questo tipo di domande è essenziale per capire quanto devi essere sicuro prima di premere il tasto Canc.

Nei commenti, rmun ha sottolineato un'eccellente formulazione del concetto di comprensione dello scopo originale del codice prima di rimuoverlo. La citazione è ora conosciuta come Fence di Chesterton . Anche se è troppo grande per essere citato direttamente in un commento, penso che meriti di essere correttamente citato qui:

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.

Tendo anche a grep per il nome di funzione / classe nel codice, che può dare alcuni vantaggi aggiuntivi che un analizzatore di codice potrebbe non avere, come se il nome fosse menzionato in un commento o in un file di documentazione, o script, per esempio. Eseguo grep sui file nell'albero dei sorgenti e memorizzo il risultato in un file; di solito il risultato fornisce un'informazione condensata: nome / percorso del file, numero della linea e la linea in cui si incontra il nome, che può dare indizi su dove la funzione / classe è chiamata o menzionata senza alcun significato semantico (al contrario di un analizzatore di codice ) e indipendentemente dalle estensioni dei file. Sicuramente non è la soluzione definitiva ma una bella aggiunta ad un'analisi.

• Identifica il codice che sembra morto (analisi statica, ecc.)
• Aggiungi un messaggio di log per ogni chiamata del codice presumibilmente non valido. È facile con funzioni / metodi; con membri statici come le costanti è più difficile. A volte puoi semplicemente contrassegnare il codice come deprecato e il runtime registrerà automaticamente un messaggio per te. Lascia il codice altrimenti intatto.
  • Registra un messaggio quando viene caricato il modulo morto: la maggior parte delle lingue è in grado di eseguire l'inizializzazione statica al momento del caricamento, che può essere salvata su supporto.
  • Assicurati che il tuo messaggio di log includa una traccia di stack ragionevole, in modo che tu capisca quale ha chiamato il presunto codice morto.
• Esegui il codice modificato attraverso tutte le tue suite di test. Le tue suite di test dovrebbero anche verificare tempi speciali, come attraversare una mezzanotte, un giro di un quarto, un giro di un anno, ecc. Guarda i registri, aggiorna la tua comprensione di ciò che è morto. Nota che i test unitari possono testare specificamente il codice morto, mentre nessun altro test di unità e nessun test di integrazione lo tocca.
• Esegui il codice modificato in produzione per alcune settimane. Assicurati che ogni processo periodico, come quei lavori cron di ETL una volta al mese, vengano eseguiti durante questo periodo.
• Guarda i log. Tutto ciò che è stato registrato non è effettivamente morto. La chiusura transitiva del grafo delle chiamate sul resto del codice morto è anche potenzialmente non morta, anche se non è stata invocata. Analizzalo. Forse alcuni rami sono morti in modo sicuro (ad esempio lavorando con un'API di un servizio ormai estinto), mentre altri non lo sono ancora. Forse un intero modulo / classe viene caricato solo per una costante definita in esso, e puoi facilmente disutilizzarlo.
• Tutto ciò che rimane è sicuro e può essere rimosso.

Oltre alle risposte esistenti menzionate potresti anche rimuovere iterativamente il codice su più versioni.

Nella versione iniziale si poteva fare un avviso di deprecazione con il blocco di codice ancora funzionante. Nella versione successiva è possibile rimuovere il blocco di codice ma lasciare un messaggio di errore che consente agli utenti di essere deprecati e non più disponibili. Nella versione finale rimuoverai il blocco di codice e tutti i messaggi.

Questo può aiutare a identificare funzionalità impreviste senza preavviso per gli utenti finali. Nel migliore dei casi il codice non fa davvero nulla e tutto ciò che accade è che il codice non necessario viene mantenuto su diverse versioni prima di essere rimosso.

Molte persone suggeriscono che la cosa "sicura" da fare è lasciare il codice se non riesci a dimostrare che non è in uso.

Ma il codice non è una risorsa, è una responsabilità.

A meno che tu possa spiegare perché è importante e puntare ai suoi test, l'alternativa "più sicura" potrebbe benissimo essere eliminarla.

Se non sei ancora sicuro, assicurati almeno di aggiungere test per esercitare il codice zombie.

Puoi utilizzare i pulsanti di selezione delle funzioni per modificare il percorso di esecuzione del tuo software in modo da ignorare completamente il codice in questione.

In questo modo puoi distribuire in sicurezza le modifiche con il codice non in uso e disattivare. Se noti alcuni errori principali relativi al codice, attiva nuovamente l'interruttore e analizza il percorso possibile.

Questo approccio dovrebbe darti sicurezza se non vedi problemi per un periodo di tempo prolungato così come la possibilità di riattivarlo live senza una distribuzione. Tuttavia, un modo ancora migliore sarebbe quello di applicare anche la registrazione extra e la copertura di test intorno all'area in questione, che fornirà ulteriori prove se è usata o meno.

Leggi ulteriori informazioni sui pulsanti qui: link

Analisi statiche, naturalmente ... e la cosa bella è che non hai bisogno di nuovi strumenti; il tuo compilatore ha tutti gli strumenti di analisi statica necessari.

Cambia semplicemente il nome del metodo (ad es. modifica DoSomething a DoSomethingX ) e poi esegui una build.

Se la tua build ha successo, il metodo, ovviamente, non viene utilizzato da niente. Sicuro da eliminare.

Se la tua build fallisce, isola la linea di codice che la chiama e controlla per vedere quali istruzioni di if circondano la chiamata per determinare come attivarla. Se non riesci a trovare i possibili casi d'uso dei dati che lo attivano, puoi tranquillamente eliminarlo.

Se sei veramente preoccupato di eliminarlo, considera di tenere il codice ma contrassegnandolo con un ObsoleteAttribute (o l'equivalente nella tua lingua). Rilasciarlo in questo modo per una versione, quindi rimuovi il codice dopo che nessun problema è stato trovato in the wild.

• Vorrei iniziare a utilizzare un analizzatore di codice per verificare se questo è un codice morto
• Vorrei iniziare a controllare i miei test e provare a raggiungere il codice. Se io sono non è in grado di raggiungere il codice all'interno di un caso di test potrebbe essere un codice morto
• Vorrei rimuovere il codice e lanciare invece un'eccezione. Per una versione viene attivata l'eccezione e nella seconda versione è possibile rimuovere l'eccezione. Per sicurezza, posizionare un contrassegno di emergenza (in Java, una proprietà di sistema) per poter attivare il codice originale, quando un cliente nota l'eccezione. Quindi l'eccezione può essere disabilitata e il codice originale può essere attivato in un ambiente di produzione.

Rimozione del codice non raggiungibile

In un linguaggio a caratteri statici di principio, devi sempre sapere se il codice è effettivamente raggiungibile o meno: rimuovilo, compila, se non ci sono errori non è raggiungibile.

Sfortunatamente, non tutte le lingue sono tipizzate in modo statico e non tutte le lingue tipizzate in modo statico sono di principio. Le cose che potrebbero andare storte includono (1) riflessione e (2) sovraccarico senza principi.

Se usi un linguaggio dinamico o una lingua con una riflessione sufficientemente potente che il pezzo di codice sotto esame possa essere potenzialmente accessibile in fase di esecuzione tramite la riflessione, non puoi fare affidamento sul compilatore. Tali linguaggi includono Python, Ruby o Java.

Se si utilizza una lingua con sovraccarico senza principi, la semplice rimozione di un sovraccarico potrebbe semplicemente spostare la risoluzione di sovraccarico su un altro sovraccarico in modo silenzioso. Alcuni di questi linguaggi consentono di programmare un avvertimento / errore in fase di compilazione associato all'uso del codice, altrimenti non si può fare affidamento sul compilatore. Tali linguaggi includono Java (usa @Deprecated ) o C ++ (usa [[deprecated]] o = delete ).

Quindi, a meno che tu non sia molto fortunato a lavorare con linguaggi rigorosi (Rust viene in mente), potresti davvero spararti ai piedi affidandoti al compilatore. E sfortunatamente le suite di test sono in genere incomplete, quindi non serve molto più.

Cue la prossima sezione ...

Rimozione del codice potenzialmente inutilizzato

Più probabilmente, il codice è effettivamente referenziato, tuttavia sospetti che in pratica i rami di codice che lo fanno riferimento non vengono mai presi.

In questo caso, indipendentemente dalla lingua, il codice è raggiungibile in modo dimostrabile e può essere utilizzata solo la strumentazione run-time.

In passato, ho utilizzato con successo un approccio a 3 fasi per la rimozione di tale codice:

1. Su ogni ramo sospettato di NON essere preso, registra un avviso.
2. Dopo un ciclo, genera un'eccezione / restituisce un errore dopo aver inserito il codice specifico.
3. Dopo un altro ciclo, elimina il codice.

Che cos'è un ciclo? È il ciclo di utilizzo del codice. Ad esempio, per un'applicazione finanziaria mi aspetto un breve ciclo mensile (con gli stipendi pagati alla fine del mese) e un ciclo annuale lungo. In questo caso, devi attendere almeno un anno per verificare che non venga mai emesso alcun avviso per lo spazio pubblicitario di fine anno che potrebbe utilizzare percorsi di codice altrimenti non utilizzati.

Si spera che la maggior parte delle applicazioni abbia cicli più brevi.

Raccomando di inserire un commento TODO, con una data, consigliando su quando passare al passaggio successivo. E un promemoria nel tuo calendario.

Rimuovere il codice dalla produzione è come pulire la casa. Nel momento in cui getti via un oggetto dalla soffitta, tua moglie ti ucciderà il giorno dopo per buttare via il regalo di ritorno del nipote del bisnipote dal loro vicino morto nel 1923.

Seriamente, dopo un'analisi superficiale che utilizza vari strumenti che tutti hanno già menzionato, e dopo aver utilizzato l'approccio per la deprecazione graduale già menzionato, tieni presente che potresti essere andato via dalla società quando si verifica l'effettiva rimozione. Lasciando che il codice rimanga e abbia la sua esecuzione registrata e assicurato che qualsiasi avviso relativo alla sua esecuzione sia definitivamente comunicato a te (o ai tuoi successori e assegnatari) è essenziale.

Se non segui questo approccio, verrai probabilmente ucciso da tua moglie. Se mantieni il codice (come ogni ricordo), puoi riposare la tua coscienza nel fatto che la legge di Moore viene in tuo soccorso e il costo dello spazio su disco usato dal codice che sembra una "pietra nella mia scarpa", riduce ogni anno e non rischi di diventare il centro di più pettegolezzi per raffreddare l'acqua e sguardi strani nei corridoi.

PS: per chiarire in risposta a un commento .. La domanda originale è "Come si sicuro eliminare .." naturalmente, nella mia risposta si presume il controllo della versione. Proprio come scavare nella spazzatura per trovare il valore presunto. Nessun corpo con alcun senso getta via il codice e il controllo della versione dovrebbe far parte del rigore di ogni sviluppatore.

Il problema riguarda il codice che potrebbe essere superfluo. Non possiamo mai sapere che un pezzo di codice è superfluo a meno che non possiamo garantire che il 100% dei percorsi di esecuzione non lo raggiungono. E si presume che si tratti di un software abbastanza grande che questa garanzia è quasi impossibile. E a meno che non legga la domanda in modo errato, l'unica volta che l'intero thread di conversazione è rilevante è per i casi durante la produzione in cui il codice rimosso può essere richiamato e quindi abbiamo un problema di runtime / produzione. Il controllo della versione non salva nessuno dietro a causa di errori di produzione, quindi il commento su "Controllo versione" non è pertinente alla domanda o al mio punto originale, vale a dire debitamente deprecato su un intervallo di tempo estremamente lungo, se proprio devi, altrimenti non t preoccupati perché il codice superfluo aggiunge relativamente un piccolo costo nello spazio su disco.

IMHO, il commento è superfluo ed è un candidato per la rimozione.

Forse il compilatore fa lo nota, ma non fa storie.

Esegui una build con ottimizzazioni complete del compilatore, orientate alle dimensioni. Quindi elimina il codice sospetto ed esegui di nuovo la build.

Confronta i file binari. Se sono identici, il compilatore ha notato e cancellato in silenzio il codice. Puoi eliminarlo dalla fonte in modo sicuro.

Se i binari sono diversi ... allora è inconcludente. Potrebbe essere un altro cambiamento. Alcuni compilatori includono anche la data e l'ora della compilazione nel file binario (e forse può essere configurato via!)

In realtà ho scoperto di recente questa esatta situazione, con un metodo chiamato "deleteFoo". In nessuna parte dell'intero codice è stata trovata una stringa diversa dalla dichiarazione del metodo, ma ho scritto saggiamente una riga di registro nella parte superiore del metodo.

PHP:

public function deleteFoo()
{
    error_log("In deleteFoo()", 3, "/path/to/log");
}

Si scopre che il codice è stato utilizzato! Alcuni metodi AJAX chiamano "method: delete, elem = Foo" che viene quindi concatenato e chiamato con call_user_func_array () .

In caso di dubbi, accedi! se hai passato abbastanza tempo senza visualizzare il registro, prendi in considerazione la possibilità di rimuovere il codice. Ma anche se rimuovi il codice, lascia il log in atto e un commento con la data per facilitare la ricerca del commit in Git per il ragazzo che deve mantenerlo!

Usa grep o qualunque strumento tu abbia disponibile per primo, potresti trovare riferimenti al codice. (Non originariamente le mie istruzioni / consigli.)

Quindi decidi se vuoi rischiare di rimuovere il codice o se il mio suggerimento potrebbe venire utilizzato:

È possibile modificare la funzione / il blocco del codice per scrivere che è stato utilizzato per un file di registro. Se nessun messaggio di questo tipo è "mai" registrato nel file di registro, è probabile che tu possa rimuovere il codice di registrazione.

Due problemi:

1. Ottenere il log da altri utenti. Forse puoi impostare un flag globale che bloccherà il programma all'uscita e chiedere gentilmente all'utente di inviarti il log degli errori.

2. Tracciamento del chiamante. In alcuni linguaggi di alto livello (ad esempio Python) puoi facilmente ottenere un traceback. Ma nelle lingue compilate dovrai salvare l'indirizzo di ritorno nel log e forzare un core dump all'uscita (punto 1).
   In C, questo dovrebbe essere abbastanza semplice: usa un blocco condizionale (ad esempio #ifdef ... #endif) per usarlo solo quando sai che funzionerà (e lo avrai testato), e semplicemente leggerai l'indirizzo di ritorno dallo stack (potrebbe o non potrebbe richiedere un linguaggio assembly inline).

Il salvataggio degli argomenti nel file di registro può essere utile o meno.

Se sai cosa fa il codice che lo circonda, testalo per vedere se si rompe. Questo è il modo più semplice ed economicamente conveniente per refactoring di un pezzo di codice su cui stai lavorando, e dovrebbe comunque essere fatto in modo di sviluppare qualsiasi modifica al codice su cui stai lavorando in primo luogo.

Se, al contrario, stai rifattorizzando un pezzo di codice in cui non conosci cosa fa, non rimuovilo . Comprenderlo prima, quindi refactarlo se lo si ritiene sicuro (e solo se si può determinare che il refactoring sarebbe un uso corretto del proprio tempo).

Ora, potrebbero esserci alcune circostanze (so che l'ho incontrato io stesso) dove il codice che è "morto" in realtà non è collegato a qualsiasi cosa . Come le librerie di codice sviluppate da un appaltatore che non sono mai state implementate da nessuna parte perché sono diventate obsolete subito dopo la consegna dell'app (perché sì, ho in mente un esempio specifico, come facevi a saperlo?).

Personalmente ho finito con la rimozione di tutto questo codice, ma è un rischio enorme che non consiglio di prendere alla leggera - a seconda di quanto codice potenzialmente potrebbe em> impatto (perché c'è sempre il potenziale che hai trascurato qualcosa) dovresti essere straordinariamente attento ed eseguire test unitari aggressivi per determinare se la rimozione di questo antico codice legacy interromperà la tua applicazione.

Detto questo, probabilmente non vale il tuo tempo o sanità mentale per cercare di rimuovere il codice in quel modo. A meno che non stia diventando un problema serio con la tua applicazione (ad esempio, non essere in grado di completare scansioni di sicurezza a causa dell'abbassamento delle applicazioni ... perché sì, ho ancora un esempio in mente), quindi non lo consiglierei a meno che non si raggiunga una situazione del genere in cui il codice ha veramente iniziato a marcire in modo incisivo.

Quindi in breve - se sai cosa fa il codice, provalo prima. Se non lo fai, puoi probabilmente lasciarlo da solo. Se sai che non puoi lasciar perdere, dedica il tuo tempo a testare il cambiamento in modo aggressivo prima di implementare la modifica.

Il mio approccio, che ho sempre considerato lo standard del settore in questo caso, non è stato menzionato finora:

Prendi un secondo paio di occhi.

Esistono diversi tipi di "codice inutilizzato" e in alcuni casi l'eliminazione è appropriata, in altri casi dovresti rifattorici, e in altri casi scappi il più lontano possibile e non guardare mai indietro. Devi capire quale è, e per farlo è meglio che tu accoppi un secondo - esperto! - sviluppatore, uno che ha molta familiarità con la base di codice. Ciò riduce significativamente il rischio di un errore non necessario e consente di apportare i miglioramenti necessari per mantenere il codice base in uno stato gestibile. E se non lo fai, a un certo punto sei a corto di sviluppatori che hanno molta familiarità con la base di codice.

Ho visto anche l'approccio alla registrazione - per essere più precisi, ho visto il codice di registrazione: ancora più codice morto che è rimasto lì per 10 anni. L'approccio di registrazione è abbastanza accettabile se stai parlando di rimuovere intere funzionalità, ma non se stai rimuovendo un piccolo pezzo di codice morto.

La semplice risposta alla tua domanda è che non puoi cancellare in modo sicuro il codice che non capisci, il che include non capire come viene chiamato. Ci saranno dei rischi.

Dovrai giudicare il modo migliore per mitigare quel rischio inevitabile. Altri hanno menzionato la registrazione. La registrazione può ovviamente dimostrare che è usata, ma non può provare che non lo è. Dal momento che il problema principale con il codice morto è che viene mantenuto, potresti essere in grado di farla franca aggiungendo un commento che dice che si sospetta che il codice sia morto e che non si faccia manutenzione su di esso.

Se il codice è sotto controllo del codice sorgente, puoi sempre scoprire quando è stato aggiunto e determinare come è stato chiamato allora.

In fin dei conti, lo capisci, lo lasci in pace o rischi.

Se lo sviluppatore del codice in questione è ancora disponibile, controlla la rimozione del codice con lui . Inoltre, leggi i commenti nel codice .

Otterrete la spiegazione corretta, perché questo codice è stato aggiunto e per quale funzione serve. Può essere facilmente supportato per il caso d'uso specifico, o addirittura potresti non avere abbastanza esperienza per giudicare se davvero non è richiesto. In casi estremi, è possibile rimuovere tutte le dichiarazioni gratuite da un programma C e non notare nulla di sbagliato (potrebbe essere necessario pochi minuti per esaurire la memoria).

È davvero una brutta cultura quando l'autore del codice si siede accanto a te, ma non vedi alcun motivo per parlare perché sei sicuro che scrive solo codice cattivo, e il tuo è tutto così perfetto. E, naturalmente, scrive solo parole casuali nei commenti, non c'è bisogno di perdere tempo a leggere.

Uno dei motivi più importanti per scrivere un commento nel codice è spiegare PERCHE 'è stato implementato in questo modo. Potresti non essere d'accordo con la soluzione, ma devi prendere in considerazione il problema.

La discussione con l'autore può anche rivelare che il codice è il residuo storico di qualcosa rimosso o mai finito, quindi è sicuro da eliminare.

Sono assolutamente d'accordo con il primo punto di Markus Lausberg: il codice dovrebbe essere sicuramente analizzato con l'aiuto di strumenti. Non ci si può fidare dei cervelli Ape con questo tipo di compito !!

La maggior parte dei linguaggi di programmazione standard può essere utilizzata negli IDE e ogni IDE che vale la pena chiamare con una funzione di "trova tutti gli usi" che è esattamente lo strumento giusto per questo tipo di situazione. (Ctrl + Shift + G in Eclipse per esempio)

Ovviamente: gli strumenti di analisi statica non sono perfetti. Bisogna essere consapevoli di situazioni più complicate in cui la decisione che il metodo in questione viene chiamato avviene solo in fase di esecuzione e non prima (chiamate tramite Reflection, chiamate a "eval" - funzioni in linguaggi di scripting ecc.)

Due possibilità:

1. Hai il 99% + copertura del test : elimina il codice e fallo con esso.
2. Non hai una copertura di prova affidabile: la risposta è quindi aggiungere un avviso deprecazione . Ad esempio, si aggiunge del codice a quel luogo che fa qualcosa di sensato (registra un avviso in un posto facilmente visibile che non sia in conflitto con l'uso giornaliero dell'applicazione, ad esempio). Quindi lasciate cuocere a fuoco lento per alcuni mesi / anni. Se non si è mai trovato alcun caso, sostituire la deprecazione con qualcosa che genera un'eccezione. Lascia stare per un po '. Infine, rimuovi tutto completamente.