Come evitare la duplicazione del codice tra progetti non correlati [duplicato]

2

Sono un appaltatore di una grande Telco, dove di solito lavoro su diversi progetti contemporaneamente.

I VCS che uso (principalmente git e mercurial) tendono a farmi mantenere le basi di codice per progetti non correlati in repository separati, e realizzo molti benefici di questo approccio.

Tuttavia, ci sono molte piccole parti di codice di utilità e funzioni di aiuto che ho scritto che sono utili in due o più progetti, e sono ben consapevole dei vantaggi di mantenere il mio codice ASCIUTTO - ad esempio a volte trovo un modo migliore per implementare un pezzo di codice e non voglio doverlo aggiornare in ogni luogo in cui ho duplicato la stessa idea.

Qual è il modo migliore per rifattorizzare questa funzionalità comune (non è sempre così semplice come copia e incolla, ma a volte lo è ..) senza creare inutili dipendenze tra progetti non correlati e senza aggiungere complessità inutile?

    
posta wim 21.05.2013 - 09:05
fonte

2 risposte

5

Bene, "piccoli bit di codice utilità" sono probabilmente i migliori non condivisi tra progetti non correlati. Basta vedere quante implementazioni di "Hello, World!" sono là fuori : -)

Seriamente, ASCIUTTO non è un assoluto. C'è un costo per la ricerca di una soluzione esistente e un costo di manutenzione relativamente alto per la condivisione del codice della libreria attraverso progetti altrimenti indipendenti. Un progetto vuole aggiungere funzionalità ma un altro progetto no, quindi cosa fai? Lo forzi o aggiungi un'opzione e ora non stai più condividendo il codice. O peggio ancora, un progetto aggiunge una funzione ma rompe qualche altro progetto. Più persone usano una libreria più difficile è cambiare.

Vedi un esempio molto grande e pratico di questo al momento nella comunità di Ruby on Rails. I progetti si basano su dozzine di gemme (pesanti bit di codice di utilità) e quindi hanno paura di aggiornarli perché qualcosa si romperà perché i "miglioramenti" in una libreria infrangono le aspettative di un'altra. È gestito in larga misura con numeri di versione ragionevoli che separano i cambiamenti dalla probabilità di rompere il codice esistente, ma comunque, c'è un sacco di spese generali per il controllo delle versioni e la gestione di quei numeri di versione, e non vale la pena per 20 linee di codice.

Come regola generale, se sei il primo a scriverlo, non è così utile. Se la Large Telco non dispone già di quella funzionalità nella base di codice, allora nessun altro ha ritenuto che fosse importante. Più probabilmente, è lì da qualche parte e non ci si può preoccupare di trovarlo, perché è più facile scriverlo da solo. E probabilmente hai ragione, ma lo sono anche i tuoi colleghi che vogliono semplicemente scriverlo da soli piuttosto che cercarlo.

In pratica, il miglior consiglio che posso dare è di conservare la tua libreria personale di frammenti di codice e portarli con te. Copia e incolla da altri progetti, se lo desideri. Fintanto che i frammenti sono piccoli e non contengono veri segreti, come le chiavi crittografiche o la formula per Coca-Cola, nessuno ti disturberà sul fatto di prendere il codice da una compagnia all'altra, tanto meno da un progetto all'altro.

E poi quando un collega chiede "hey, conosci un buon modo per fare X" puoi semplicemente copiare e incollare il codice in un'email o su un IM e diventare l'eroe dell'ora.

    
risposta data 21.05.2013 - 11:06
fonte
4

Calcola le cose comuni in una o più librerie. Metti la libreria nel proprio repository e, nei singoli progetti, aggiungi un po 'di logica allo script di build per assicurarti di avere la versione corretta della libreria. Potresti o meno voglia di subrepos per questo; questione di gusti, davvero.

    
risposta data 21.05.2013 - 09:51
fonte

Leggi altre domande sui tag