Elimina il codice sorgente inutilizzato dal repository o mantieni una cartella di archivio?

5

Nella nostra azienda, abbiamo un repository di controllo a versione singola con una struttura come questa:

/client1_product
/client2_product
/...
/shared_lib1
/shared_lib2
/...

Dopo quasi due decenni di sviluppo, questa lista è diventata lunga e confusa, mescolando progetti attivi con quelli morti da tempo. L'orientamento è difficile per i nuovi arrivati. Stiamo discutendo di due opzioni.

Elimina vecchi elementi:

  • Rende chiaro che questo non deve mai essere più toccato.
  • Tutto, ovviamente, è ancora recuperabile tramite il controllo della versione.

Spostamento di elementi vecchi in una cartella "archivio":

  • Lontano dagli occhi, ma ancora alla portata.
  • Per alcuni, questo non è abbastanza buono.

Come possiamo migliorare la chiarezza all'interno dei nostri repository?

    
posta Hauke 16.07.2015 - 10:57
fonte

2 risposte

5

Il problema con l'eliminazione è che sono "fuori dalla vista" e quindi "fuori di testa". Il problema con l'archiviazione è che i link o i riferimenti relativi non verranno più applicati. Tricky ...

Personalmente vorrei eliminarli e taggare le revisioni che questi sono stati cancellati. Ciò consente di recuperare facilmente i progetti morti, ma anche di essere nascosti ma ancora noti. Aggiungi una descrizione per ciascuno dei progetti morti in modo che qualcuno sappia cosa hanno fatto, se decidono di cercare il vecchio codice da resuscitare o compilare.

    
risposta data 16.07.2015 - 11:18
fonte
11

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).

risposta data 16.07.2015 - 11:22
fonte