Come determinare se esiste un utile codice eliminato nel controllo del codice sorgente?

Quindi stavo leggendo questa domanda. Devo rimuovere il codice senza riferimento?

Alcuni dei consigli erano di eliminare il codice senza riferimento poiché il codice è nel controllo del codice sorgente per riferimento nel caso sia necessario in un secondo momento.

Come organizzi questo codice cancellato in modo che una versione successiva di te (o di qualche altro programmatore) possa trovarlo in seguito? Crea un ramo separato o taggalo in qualche modo nel controllo del codice sorgente?

Non ho mai resuscitato il codice cancellato dal controllo del codice sorgente prima, l'ho usato principalmente per tenere traccia delle modifiche sul codice che è ancora attivo. Ho fatto riferimento a rami prima quando contenevano il lavoro sperimentale di qualcun altro, quindi forse è un buon modo per contrassegnare interessanti sezioni di codice che vengono eliminate nel trunk?

A meno che tu non stia sperimentando in un ramo e non sei ancora sicuro di quale soluzione alla fine verrà reintegrata, di solito non fai riferimento al codice eliminato.

In rare occasioni, potresti cercare esplicitamente il codice rimosso che ricordi vagamente di aver risolto un problema che hai in questo momento . Ma la ragione più tipica per cui vedrai il codice cancellato è quando guardi attraverso il backlog per capire qualcosa sul codice o sul comportamento corrente di un'applicazione rispetto al suo codice storico o comportamento.

In particolare, potresti essere ...

• fare una revisione generale del codice / comprendere un refactor
• cercando il commit che ha introdotto il bug X
• soddisfare la tua curiosità / cercare l'impegno che ha risolto un bug
• reimplementare una funzionalità o funzionalità simile
• comprensione del codice o dei dati che sembrano funzionare in combinazione con codice che non esiste

... eccetera.

E in quei casi, in genere non stai resuscitando il vecchio codice. Stai solo capendo qualcosa che vedi in questo momento usando il codice rimosso per contesto o guida.

Immagino che la risposta sia: alla stragrande maggioranza dei programmatori non interessa fare riferimento al codice eliminato. Per diverse ragioni. Alcuni motivi che mi vengono in mente sono:

• Probabilmente, soprattutto, pura pigrizia ...

• Molti non hanno mai sentito la necessità di resuscitare un po 'di codice, quindi non hanno alcuna esperienza che li motiva a rendere più facile la risurrezione del codice.

• La maggior parte del codice eliminato viene eliminato per un motivo. Di solito, viene sostituito da un altro codice, migliore, funzionalmente equivalente o più potente. Perché qualcuno dovrebbe voler resuscitare il codice inferiore?

  Nota che anche questo è di nuovo un problema psicologico: la maggior parte dei programmatori è abbastanza orgogliosa dei risultati del proprio lavoro. Come è mai venuto in mente che c'era ancora un valore in ciò che hanno sostituito?

• Poiché la maggior parte del codice non viene puramente eliminata, ma sostituita, le interfacce che sono state modificate nella transizione forniscono informazioni sufficienti se è davvero necessario rintracciare il codice eliminato a causa di alcune regressioni introdotte dal nuovo codice.

Ma, indipendentemente da quante ragioni più o meno valide puoi mettere dietro questo disprezzo per il codice morto, penso che sia davvero un "non importa" da parte dei programmatori. E anche se provi a contrassegnare le cose eliminate in un modo o nell'altro, preparati a essere completamente ignorato con quello sforzo ...

Questa domanda probabilmente ricade su "Come mantenere la tracciabilità dei check-in VCS rispetto al database dei bug e ai requisiti di sistema?"

Le volte in cui le persone vanno a resuscitare il codice dal controllo del Sorgente tendono ad essere quelle volte in cui si scopre che qualcosa si è rotto involontariamente e deve essere riportato.

La cosa più importante in quello scenario per chi cerca un bit specifico di codice rimosso è che può facilmente rintracciarlo guardando attraverso il database dei requisiti e lo strumento di tracciamento dei bug; perché è probabile che stiano cercando il requisito specifico o parole che descrivono la funzionalità. È improbabile che conoscano il nome del file sorgente o la classe / funzione che è stata rimossa.

Se vuoi tenere traccia di un codice interessante / sperimentale che deve essere rimosso prima del rilascio, puoi semplicemente rintracciarlo con alcuni ticket "bug" lungo le righe di "Rimuovi codice inutilizzato per ..." . O forse introdurre un nuovo tipo di ticket nel sistema per la funzione Prototype .

Quindi, per rispondere direttamente alla domanda - non usare rami / tag nel tuo sistema VCS per tracciare il codice cancellato - usa il tuo strumento di tracciamento delle modifiche.

Il consiglio è destinato alle persone che mantengono il codice obsoleto nella base di codici "per ogni evenienza". Poiché il codice esisterà ancora nel controllo del codice sorgente, non dovresti temere di eliminarlo. Non organizzi davvero il codice cancellato in quanto tale, poiché il punto è che non è più necessario. Basta aggiungere un messaggio di commit che indica cosa è stato modificato ed eliminato nel commit. Il messaggio di commit più rilevante per il codice eliminato è il messaggio al momento dell'aggiunta iniziale del codice, non il messaggio quando è stato nuovamente eliminato.

"Il lavoro sperimentale" è davvero un problema diverso. Dovresti avere un ramo separato per quello.