Quando è 'clonazione', piuttosto che riutilizzare, una soluzione di progettazione accettabile per moduli?

Mi sembra che tu stia pensando di ramificare il tuo codice, che fondamentalmente sta per clonare il tuo codice base per lo sviluppo e il supporto dei tuoi due progetti, pur consentendo la flessibilità di unire le modifiche secondo necessità. Così si finisce con un nuovo ramo nel sistema di controllo della versione e si decide se continuare il supporto per la versione originale nel ramo o nella linea principale.

Se stai pensando di eliminare gradualmente la tua versione iniziale, potresti voler lanciare il supporto in una succursale e mantenere la tua seconda versione sulla linea principale. In entrambi i casi, tuttavia, la manutenzione potrebbe comportare una modifica utile sia nella versione vecchia che in quella nuova, pertanto è consigliabile gestire la ramificazione / fusione in modo da poter sfruttare i vantaggi delle modifiche senza dover modificare due singoli progetti.

Forse ho semplificato eccessivamente la mia risposta qui, tuttavia è importante sottolineare che si verificheranno gravi problemi di gestione e di pianificazione dei colli di bottiglia se si sceglie di mantenere due prodotti separati quando si potrebbe altrimenti condividere gran parte della base di codice tra il due prodotti.

L'altra alternativa potrebbe essere quella di suddividere il prodotto in moduli più piccoli. Uno strato base comune in cui può risiedere tutto il codice comune non modificato e una coppia di prodotti unici e dipendenti come uno strato superiore alla base. Anche questo può avere i suoi problemi, ma può essere relativamente semplice da gestire se supportato da un buon processo di compilazione / rilascio automatico.

Questo suona come uno di quei problemi di business che a volte devi solo gestire e gestire. Ad esempio, abbiamo clienti nel settore farmaceutico e una volta che convalidano una versione del nostro software per la loro linea di produzione, non possono cambiare le versioni senza una quantità significativa di documenti e di convalida. Manteniamo filiali personalizzate della nostra base di codici per questi clienti in cui "garantiamo" (come criterio) che le uniche modifiche presenti sono correzioni di bug che sono state ritenute rilevanti per il loro processo e vengono fornite solo su loro richiesta.

Considerati tali limiti, ritengo che l'opzione migliore sia quella di inserire il codice in due rami. Uno normalmente lo fa nel sistema di controllo della versione, non una semplice copia del file system. Quando si diramano nel sistema di controllo della versione, la cronologia comune viene mantenuta, e l'integrazione delle correzioni dei bug dal nuovo ramo al ramo legacy può essere eseguita automaticamente e nel peggiore dei casi manualmente con l'assistenza della macchina. Vorrei non metterlo nella categoria della programmazione di copia-incolla, che in genere guardo dall'alto in basso.

Questo modello di sviluppo è in realtà abbastanza comune. Quando si rilascia una versione principale di alcuni software, chiamatela versione 1.0, in pratica si desidera mantenerla invariata mentre si carica e si avvia la versione 2.0. Intorno al momento del rilascio, si crea un ramo fuori dal tronco principale chiamato 1.0 (o solo un tag / etichetta) per contrassegnare chiaramente ciò che è stato spedito. Mentre lavori su 2.0, o mentre le persone usano il tuo software, si incontrano bug e si trovano le correzioni.

Ora vuoi veramente applicare quelle correzioni sia sul ramo 1.0 che sul trunk principale, così fai. Ci sono diversi approcci a questo. Uno è semplicemente applicare le stesse modifiche agli stessi file su entrambi i rami 1.0 e principale. Questo può essere il più semplice ma è un po 'soggetto a errori.

Un altro è applicare la correzione su un ramo e quindi integrare i file modificati da un ramo all'altro. Nei progetti di grandi dimensioni questo può spesso essere fatto automaticamente, poiché i file su entrambe le diramazioni potrebbero non essere cambiati dal rilascio e sono identici. Il sistema di controllo della versione conosce la cronologia di entrambi i rami, quindi l'applicazione delle correzioni su 1.0 e l'integrazione da 1.0 a main è probabilmente la scelta migliore, in quanto il sistema di controllo delle versioni non sarà generalmente confuso dal nuovo sviluppo effettuato sui file post-1.0 e può applicare le correzioni automaticamente. Andare in senso inverso non è raccomandato perché il sistema conrol della versione non è in grado di distinguere le differenze tra le modifiche sul file post-1.0 che sono di nuovo sviluppo e quelle che risolvono i bug. Ciò potrebbe causare l'introduzione di codice inappropriato nel ramo 1.0.

A volte, i file post-1.0 sul ramo principale sono così diversi da quello spedito da rendere impossibile l'integrazione automatica. In questo caso, non è necessario applicare la correzione nel nuovo codice, oppure devi semplicemente fare attenzione e applicarla manualmente in entrambi. Qualunque sia il percorso che scegli, controlla sempre attentamente le modifiche prima di controllarle.