Poiché la cronologia è preservata nel controllo della versione, non vi è assolutamente alcun motivo per non rimuovere il codice che non è necessario. A proposito, questo vale anche per il codice commentato all'interno della fonte: non commentare blocchi di codice, basta rimuoverli; se ne avrai bisogno più tardi , il controllo della versione è tuo amico.
Più tardi potrebbe essere anche in un'ora. Il buonsenso può stabilire che se pensi che avrai bisogno di un intero progetto o di un pezzo di codice in un'ora, allora è meglio tenerlo o commentarlo. Scorporrei tale pratica, dal momento che il ripristino degli elementi rimossi dovrebbe comunque essere una questione di secondi (soprattutto perché ricordi esattamente cosa è stato rimosso). Spostare il progetto nella directory di archivio e quindi spostarlo di nuovo richiederà lo stesso periodo di tempo per il ripristino. Per quanto riguarda il codice commentato, c'è un enorme rischio che finisca per dimenticare di rimuoverlo se sembra che in realtà non ne abbia bisogno.
La rimozione di interi progetti è particolarmente importante per le persone che aderiscono al progetto. In SVN, ad esempio, la nuova persona deve eseguire il checkout dell'ultima revisione per ottenere il codice sorgente, il che significa scaricare anche i progetti archiviati. Ciò può avere un impatto sul tempo perso a fare il checkout originale, tempo che puoi ridurre considerevolmente semplicemente rimuovendo i progetti che non ti servono, invece di spostarli in una directory specifica.
Per garantire prestazioni ottimali del tuo team, assicurati che:
-
La cronologia del controllo della versione rimarrà per sempre. Ho visto molti casi in cui i team migrano verso un controllo di versione diverso e non si preoccupano di migrare la cronologia (anche se è relativamente facile da fare). C'è stato anche un caso in cui il team ha deciso di rimuovere le vecchie revisioni per liberare spazio sul proprio server (sì, lo so, lo trovi anche estremamente stupido).
-
I log dei messaggi sono abbastanza espliciti e i commit sono abbastanza granulari da essere in grado di trovare rapidamente il codice rimosso quando necessario. Il tagging potrebbe essere usato per quello (sebbene io sia personalmente contrario a tale uso, incluso in questo caso particolare).
-
Gli sviluppatori, in particolare i nuovi arrivati, sanno come utilizzare la cronologia e come recuperare correttamente il codice rimosso. Il caso peggiore è qualcuno che non sa come farlo e copia e incolla il codice a mano e poi esegue il commit.
Il problema principale è che il controllo della versione non sa che il codice esiste già; questo diminuisce la tracciabilità (è come se tutto questo codice fosse stato scritto da zero) e aumenta il footprint di utilizzo del disco (dal momento che il controllo della versione dovrebbe memorizzare il codice invece di riferirsi solo a un commit precedente).