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

Sono uno sviluppatore indipendente che lavora su più progetti Android. Sto riscontrando problemi con il mantenimento della stessa funzionalità su progetti diversi. Ad esempio, tre delle mie app usano le stesse 2 classi; dal momento che sono progetti diversi, quando ho bisogno di fare un cambiamento in quelle classi, devo farlo tre volte. Esiste una soluzione semplice a questo tipo di problema comune?

Separare il codice condiviso in una libreria e includere 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 ciò contribuirà a mantenere la separazione delle preoccupazioni applicando la modularità. Il costo è che potrebbe essere necessario un po 'di lavoro per separarsi; il vantaggio è una migliore manutenibilità futura. Inoltre, se lo decidi, puoi rilasciare la libreria separatamente (commercialmente o come open source) dalle tue applicazioni.

Controllo della versione. Idiota. 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. Utilizzare il sottomodulo nei progetti che ne hanno bisogno. Quando si aggiorna il sottomodulo, è possibile eseguire il pull delle modifiche ad altri progetti con un singolo comando.

Nessun altro ha ancora menzionato la spada a doppio taglio, quindi aggiungerò i miei 2 centesimi. Se hai più progetti e tutti condividono del codice riutilizzabile, secondo le buone pratiche / principi di programmazione (DRY per esempio), dovresti posizionare il codice in un posto globale e strutturarlo in modo che possa essere condiviso da tutti i tuoi progetti senza alcuna modifica. In altre parole, definire le interfacce come generiche e abbastanza comuni per soddisfare tutti.

Ci sono alcune opzioni per farlo: 1) Crea un progetto base da cui dipendono gli altri. Questo progetto può creare una distribuzione binaria utilizzata da altri progetti. 2) Tirare un modello open source all'interno dell'organizzazione. Avere il codice comune come proprio ramo di codice e fare in modo che altri progetti inseriscano il codice nello stesso modo in cui si prenderebbe il codice sorgente da qualsiasi OSS online.

Ora ecco dove arriva la spada ...

Mettere il codice in un luogo comune da cui dipendono altri progetti / persone 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 del codice da cui dipendono altri 3 progetti. Hai ripetuto di nuovo tutti questi test per assicurarti che non siano state introdotte condizioni ai bordi?

Il codice comune deve anche essere creato con molta più attenzione e le interfacce dei moduli devono essere progettate molto meglio perché quel codice deve ospitare non uno ma 4 client e ognuno di questi potrebbe usare questo codice con una differenza così minima.

Se i tuoi progetti hanno cicli di rilascio diversi, devi essere ancora più attento alla gestione del codice comune. Non puoi semplicemente apportare modifiche al codice comune perché il progetto B necessita di nuove funzionalità, se hai 3 giorni di distanza dal taglio dell'immagine finale per il progetto C.

Non sto dicendo che la biblioteca comune non sia la soluzione giusta. Sono un grande sostenitore di DRY e in precedenza ho creato e supportato codice comune e continuo a farlo. Volevo solo dirlo che semplicemente rendere comune il codice avrebbe le sue spese.

Se sei l'unico a riutilizzare questo codice, non è così male. Se hai un team di ingegneri e iniziano a utilizzare il codice comune, le spese aumentano ancora di più. Se ne sono coinvolti altri, aspettati che il posizionamento del codice in una libreria comune impieghi 3 volte il tempo necessario per arrivare a un punto in cui pensi che sia "completo". Dovrai: a) rendere la libreria più solida per proteggere da tutti i tipi di condizioni limite e di utilizzo non valido, b) fornire documentazione in modo che altri possano utilizzare la libreria e c) aiutare altre persone a eseguire il debug quando usano la libreria in modo tale non ho previsto e la tua documentazione non ha riguardato il loro caso d'uso specifico.

Alcuni suggerimenti che posso offrire:

1. Avere il codice comune coperto da test di unità automatizzati può fare molto e darti un'idea del fatto che quando fai una modifica, non hai semplicemente interrotto qualche altro progetto.
2. Vorrei solo inserire funzionalità molto stabili nel codice comune. Se hai scritto una lezione l'anno scorso per fare la gestione del timer e non l'hai cambiata in 9 mesi e ora hai altri 3 progetti che hanno bisogno di timer, allora sicuramente è un buon candidato. Ma se hai appena scritto qualcosa la scorsa settimana, beh ... non hai molte opzioni (e odio copiare / incollare il codice probabilmente più del prossimo ragazzo) ma ci penserei due volte su come renderlo comune.
3. Se il pezzo di codice è banale ma l'hai usato in diversi punti, forse è meglio mordere il proiettile, lasciare DRY da solo e lasciare vivere più copie.
4. A volte vale la pena non semplicemente mettere il codice comune in una posizione comune e fare in modo che tutti lo facciano riferimento. Ma piuttosto considera il codice comune come il suo rilasciabile con le versioni, le date di rilascio e tutto il resto. In questo modo il progetto C può dire "Uso la libreria comune v1.3" e se il progetto D necessita di nuove funzionalità, si lascia v1.3 da sola, la versione v1.4 e il progetto C non ne risentono. Tieni presente che è MOLTO, MOLTO più costoso trattare il codice comune come un prodotto proprio piuttosto che semplicemente controllarlo in un luogo comune.

Questa è una soluzione idealizzata e potrebbe richiedere alcuni sforzi per iniziare a lavorare.

Il principio DRY afferma che dovrebbe esserci un'unica fonte autorevole di verità. Ciò determina l'uso di un repository a sorgente singola per tutta la logica del programma, senza duplicazioni; file organizzati per promuovere la condivisione e il riutilizzo dei documenti.

I requisiti pragmatici della comunicazione in un ambiente distribuito e multi-team suggeriscono che dovrebbero esserci più repository indipendenti, uno per ciascun progetto o collaborazione.

Affronterei questo problema presentandomi all'inevitabile: dovrai adottare entrambi gli approcci contemporaneamente e useremo lo scripting e l'automazione per appianare il fatto che gli approcci sono contraddittori.

:-)

L'unico repository unificato sarà la tua singola 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 costruirà 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 l'insieme di repository secondari, derivati ​​o downstream. Gli script hook post-commit sul repository autorevole aggiorneranno tutte le posizioni intermedie e, per ciascuna a sua volta, verificheranno se è stata modificata e effettueranno lo stesso commit nel repository secondario corrispondente se viene rilevata una modifica.

In questo modo, i repository secondari multipli vengono mantenuti in sincronia con il repository di origine autorevole singolo e il processo di compilazione garantisce che i repository secondari contengano tutti i documenti (possibilmente condivisi) e altri file necessari per il completamento 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 posto e che tutte le copie siano mantenute coerenti e aggiornate.