Come mantenere gli stessi frammenti di codice su più progetti [chiuso]

Separa il codice condiviso in una libreria e includi la libreria nei progetti.

Come sviluppatore Android, stai presumibilmente usando Java. Prendi in considerazione l'utilizzo di uno strumento di gestione delle dipendenze come Maven o Ivy .

Un effetto collaterale è che questo aiuterà a mantenere separazione delle preoccupazioni attuando la modularità. Il costo è che potrebbe essere necessario del lavoro per separare; il vantaggio è una migliore manutenibilità futura. Inoltre, se decidi di farlo, puoi rilasciare la libreria separatamente (commercialmente o come open source) dalle tue applicazioni.

Controllo versione. Git. Git Submodules.

Metti i tuoi progetti sotto controllo di versione, usando un dvcs come git o mercurial ecc. Metti il codice condiviso in un sottomodulo in git. Usa il sottomodulo nei progetti che ne hanno bisogno. Quando aggiorni il sottomodulo, puoi trasferire le modifiche ad altri progetti con un singolo comando.

Nessun altro ha menzionato la spada a doppio taglio, quindi aggiungerò i miei 2 centesimi. Se hai più progetti e tutti condividono del codice riusabile, in base a buone pratiche di programmazione / principi (ad esempio DRY), devi posizionare il codice in un luogo globale e strutturarlo in modo tale che possa essere condiviso da tutti i tuoi progetti senza modifiche. In altre parole, definisci le interfacce generiche e abbastanza comuni per soddisfare tutti.

Ci sono poche opzioni per farlo: 1) Creare un progetto di base da cui dipendono gli altri. Questo progetto può creare una distribuzione binaria che altri progetti consumano. 2) Tirare un modello open-source all'interno dell'organizzazione. Avere codice comune è il proprio ramo di codice e fare in modo che altri progetti eseguano il codice nello stesso modo in cui si prenderà il codice sorgente da qualsiasi OSS online.

Ora qui è dove entra la spada ...

Inserire codice in un luogo comune su cui altri progetti / persone dipendono può diventare piuttosto costoso. Diciamo che hai un pezzo di codice e altri 4 progetti dipendono da questo. Uno dei tuoi clienti che utilizza il progetto A trova un bug e devi fare una correzione. Ti affretti a risolvere il problema e quel cliente è felice. Ma hai appena modificato un codice da cui dipendono altri 3 progetti. Hai ripetuto di nuovo tutti quelli per assicurarti che non siano state introdotte condizioni marginali?

Il codice comune deve anche essere creato molto più attentamente e le interfacce dei moduli devono essere progettate in modo molto migliore perché quel codice deve ospitare non uno ma 4 client e ognuno di questi potrebbe semplicemente usare questo codice con una differenza così lieve.

Se i tuoi progetti sono in cicli di rilascio diversi, devi essere ancora più attento a gestire il codice comune. Non puoi semplicemente apportare modifiche nel codice comune perché il progetto B ha bisogno di nuove funzionalità, se mancano 3 giorni al taglio dell'immagine finale per il progetto C.

Non sto dicendo che la libreria comune non è la soluzione giusta. Sono un strong sostenitore di DRY e ho creato e supportato codice comune prima e continuo a farlo. Volevo solo metterlo lì fuori che semplicemente facendo codice comune avrà le proprie spese.

Se sei l'unico a riutilizzare questo codice, non è così male. Se hai un team di ingegneri e iniziano a usare il codice comune, le spese aumentano ancora di più. Se altri sono coinvolti, si aspetti di inserire il codice in una libreria comune per impiegare 3 volte il tempo necessario per arrivare a un punto in cui pensi che sia "completo". Sarà necessario a) rendere la libreria più robusta per proteggere da tutti i tipi di condizioni marginali e utilizzo non valido, b) fornire documentazione in modo che altri possano utilizzare la libreria ec) aiutare altre persone a eseguire il debug quando utilizzano la libreria in un modo non ho previsto e la tua documentazione non copre il loro caso d'uso specifico.

Pochi suggerimenti che posso offrire:

1. Avere un codice comune coperto da test unitari automatizzati può fare molto e ti dà un po 'di idea che quando apporti una modifica, non hai interrotto solo un altro progetto.
2. Metterei solo funzionalità molto stabili nel codice comune. Se hai scritto un corso lo scorso anno per gestire il timer e non lo hai cambiato in 9 mesi e ora hai altri 3 progetti che hanno bisogno di timer, assicurati che sia un buon candidato. Ma se hai appena scritto qualcosa la settimana scorsa, beh ... non hai molte opzioni (e odio il codice copia / incolla probabilmente più del prossimo) ma ci penserei due volte prima di renderlo comune.
3. Se un pezzo di codice è banale ma lo hai usato in più punti, forse è meglio mordere il proiettile, lasciare DRY da solo e lasciare vivere più copie.
4. A volte vale la pena di non inserire semplicemente il codice comune in un percorso comune e farne riferimento da tutti. Piuttosto, tratta il codice comune come se fosse rilasciabile con versioni, date di rilascio e altro. In questo modo il progetto C può dire: "Io uso la libreria comune v1.3" e se il progetto D ha bisogno di nuove funzionalità, si lascia solo la versione 1.3, si rilascia la versione 1.4 e il progetto C non ne risente. Tieni presente che è MOLTO, MOLTO più costoso trattare il codice comune come prodotto proprio piuttosto che averlo semplicemente controllato in una posizione comune.

Questa è una soluzione idealizzata e potrebbe richiedere qualche sforzo per funzionare.

Il principio DRY afferma che dovrebbe esserci un'unica fonte autorevole di verità. Questo impone l'uso di un singolo repository source per tutta la logica del programma, senza duplicazione; file organizzati per promuovere la condivisione e il riutilizzo dei documenti.

I requisiti pragmatici della comunicazione in un ambiente distribuito e multi-team suggerisce che ci dovrebbero essere più repository indipendenti, uno per ogni progetto o collaborazione.

Vorrei affrontare questo problema inviando l'inevitabile: dovrai adottare entrambi gli approcci contemporaneamente, e useremo scripting & automazione per appianare il fatto che gli approcci sono contraddittori.

: -)

L'unico repository unificato sarà la tua unica fonte autorevole. Il processo di compilazione per ciascun progetto copierà tutti i file utilizzati da quel progetto (e solo quei file) in una posizione intermedia, quindi creerà da quella posizione intermedia. (Unison o qualche strumento simile può essere usato per spostare delta invece di interi file).

Queste posizioni intermedie possono essere utilizzate come copie di lavoro locali per il set di repository secondari, derivati o downstream. Gli script di hook post-commit sul repository autorevole aggiorneranno tutte le posizioni intermedie e, per ciascuna a sua volta, verificherà se è stata modificata e assegneranno lo stesso commit al repository secondario corrispondente se viene rilevata una modifica.

In questo modo, i repository secondari multipli vengono mantenuti sincronizzati con il singolo repository di origine autorevole e il processo di generazione garantisce che i repository secondari contengano tutti i documenti (eventualmente condivisi) e altri file necessari per il successo della compilazione . Infine, e soprattutto, il processo di sviluppo e creazione garantisce che i file vengano modificati in un unico posto e in un solo luogo e che tutte le copie siano coerenti e aggiornate.