Quando un progetto ha raggiunto la fine del ciclo di vita e viene ritirato, sia perché la tecnologia è obsoleta, è stata riscritta una versione più recente del programma, oppure non risolve più un problema che è necessario risolvere, ciò che dovrebbe essere fatto con il codice? Dovrebbe essere cancellato o conservato per riferimento futuro?
Questo vale anche per i progetti che qualcuno potrebbe sviluppare come appaltatore e la società che ne aveva bisogno cessa l'attività.
Keep it.
Potresti dover controllare un giorno il codice per vedere ad es. ipotesi, o come una cosa specifica è stata risolta ("hai avuto qualcosa che ha fatto questo, e vogliamo la stessa cosa") ed è un po 'più facile se ce l'hai davvero.
I repository sorgente sono davvero economici da tenere in un angolo di un server ufficiale da qualche parte.
Se il codice è diventato così naturale, dovresti non eliminarlo. Gli utenti sono molto bravi a disperatamente bisogno di aiuto 5 minuti dopo aver distrutto la tua capacità di supportarlo.
Con il lato contrattuale della tua domanda potresti essere limitato da problemi di riservatezza. Avevo un'agenzia governativa che mi proibiva espressamente di portare qualsiasi cosa fuori sede, che fosse elettronica o fisica. Ma se riesci a farla franca, ti incoraggio a mantenere un backup di tutto ciò che fai per le altre parti: questo approccio mi ha reso un eroe in diverse occasioni.
Credo che la mia risposta si riduca a: aspetto di aver bisogno del codice un giorno.
Lo spazio di archiviazione è davvero economico al giorno d'oggi, quindi personalmente conserverei un backup di archivio per ogni evenienza.
Metti sotto una licenza FOSS.
Se non è possibile, documentatene ogni piccola parte a partire da specifiche, progettazione, bug affrontati e risolti e pubblicate questo rapporto con una licenza FOSS. Questo rapporto ti aiuterà, e, altri, a imparare dai tuoi errori. Inoltre, se qualcuno vuole scrivere un programma o un programma simile alle specifiche esatte, dovrà ringraziarlo.
Raccomando di utilizzare un sistema di controllo della versione (git / mercurial / subversion) e di eliminare il codice non più usato-usato.
Basta usare il sistema di controllo versione come backup per il codice "morto". Quindi, a meno che non si tratti di un'API pubblica, procedi con l'eliminazione! Il codice eliminato sarà sempre in una revisione in cui puoi andare quando necessario.
Se si tratta di un'API pubblica, il processo è un po 'più lungo e noioso. Per prima cosa devi contrassegnarlo come deprecato, in modo che i tuoi utenti API possano sapere cosa sta per succedere, quindi nelle versioni future potresti eliminare le implementazioni e lasciare le classi / interfacce / funzioni definite e contrassegnate come deprecate.
Usando VCS, sia distribuito che centralizzato, avrai accesso al codice cancellato / deprecato, quindi non c'è molto da temere.
Lo spazio di archiviazione è economico, quindi cosa ottieni effettivamente eliminando il codice?
Che guadagni mantenendo il codice in un archivio in cui puoi accedervi, ma non perderà nulla per caso?
Cosa sospettiamo tutti che succederà 5 minuti dopo aver eliminato l'ultima copia (inclusi i backup) di quel codice?
Le risposte a queste domande ti diranno se tenerlo o meno.
E, naturalmente, aprire il sourcing è sempre un'opzione che potrebbe dargli nuova vita in modi che non ti saresti mai aspettato.
Conserva il codice ma rimuovilo dai progetti, dal processo di compilazione e dal VCS. Sarà nel VCS quando ne avrai bisogno. Ma quando non lo vedi direttamente, il progetto attuale è più facile da capire.
Elimina.
Solo perché possiamo memorizzare qualcosa non significa che dovremmo.
"la tecnologia è obsoleta". Cancellalo. Obsoleto è obsoleto. Non tornerà mai magicamente utile se non come dispositivo di trama in serie TV.
"una versione più recente del programma è stata riscritta". Cancellalo. Dopo 90 giorni di utilizzo del nuovo software ci saranno abbastanza nuovi dati che non possono essere trasferiti alla vecchia versione che è possibile eliminarlo in sicurezza. È inutile.
"non risolve più un problema che è necessario risolvere". Potresti tenerlo solo nel caso in cui il problema riemerge. Le probabilità dello stesso problema (nello stesso contesto, che può essere risolto dallo stesso problema) sono quasi pari a zero.
Il codice non è un prezioso artefatto che i futuri archeologi vorranno. Non è un cimelio che trasmetteresti ai tuoi figli. Non è un patrimonio aziendale che fa soldi o riduce i costi. È solo confusione mentale.
Cancellalo. Per favore.
"progetti che qualcuno potrebbe sviluppare come appaltatore". Il cliente possiede il codice. Elimina la tua copia al più presto. Quando apporti modifiche alla loro copia, la tua copia è inutile e confusa.
"e l'azienda che aveva bisogno di loro ha cessato l'attività". Questo è un problema per gli avvocati che gestiscono i beni dell'azienda defunta. Non è un tuo problema. Una copia duplicata del codice non aiuta nessuno. Elimina la tua copia dopo aver ricevuto il pagamento finale se hai ancora dei soldi dovuti.
Leggi altre domande sui tag code-reuse storage