L'approccio migliore per mantenere due prodotti software in una base di codice

Libreria / divisione del progetto

Se le personalizzazioni per ciascun client sono qualcosa che può essere facilmente modularizzata, è sufficiente scrivere una o più classi con una base astratta che definisca questi comportamenti personalizzati all'interno del programma. Trova tutti i punti del tuo progetto in cui contenga catene lunghe se non altro per comportamenti client diversi e passa attraverso il disturbo di A) fornendo un comportamento predefinito e B) permettendoti di personalizzare quel comportamento. Quindi scrivi progetti per ogni cliente che fornisce la propria implementazione, idealmente nel proprio progetto individuale con riferimento alla base o forse l'uso di plugin per modificare il comportamento semplicemente con l'esistenza di una libreria esterna (Java ha il supporto per questo ad esempio). In questo modo, le personalizzazioni sono nelle loro librerie, ma il programma è la stessa.

Codice suddiviso

Tuttavia, poiché queste cose vanno, le personalizzazioni sono raramente così pulite, quindi l'alternativa è copiare completamente il codice di base. Il vantaggio principale in questo consiste nell'eliminare il rischio di creare bug tra client. La modifica del comportamento per un client è garantita per non avere un impatto su nessun altro client. Se questo è un problema comune, questo è un vantaggio considerevole. Detto questo, lo maggiore svantaggio di questo approccio è l'inferno di manutenzione. Ogni modifica che deve essere apportata per un cliente deve essere applicata a tutti gli altri progetti che richiedono test per ogni altro progetto. Probabilmente si può applicare solo a un progetto, ma si rischia quindi che l'elenco di funzionalità e / o correzioni di bug applicati a ciascuna versione diventi quasi impossibile da tenere traccia di.

Conclusione

Certamente la soluzione facile e veloce è la suddivisione del codice, ma sconsiglio vivamente che se puoi aiutarlo. La cosa intelligente sarebbe prendere il tempo per modularizzare il tuo progetto. Prendilo da un programmatore che ha già avuto modo di farlo prima. Inutile prendere la facile strada di campagna sulla strada meno percorsa se alla fine la facile strada di campagna porta direttamente in un vulcano attivo. Se non riesci a far capire al tuo capo che è meglio per la salute del progetto, spiegalo in termini di debito tecnico e costi di manutenzione che quasi sicuramente verranno dopo.

Hai due applicazioni. Questi sembrano prodotti separati che, sebbene abbiano un'origine comune, non si sviluppano allo stesso modo.

Dal punto di vista estetico, le applicazioni condividono i loro dati, forse anche il loro modello, ma non le loro view / viewmodels.

Se sembra uguale ma si comporta in modo diverso, significa che ci sono diversi controller coinvolti. Sembra che al momento ci sia un percorso divergente per entrambe le applicazioni. A questo punto è davvero un mix di ingegneria del software e strategia di prodotto. Quanto puoi allontanare le funzionalità extra dall'applicazione originale? È possibile configurarlo come un prodotto completamente diverso?

Quindi ci sono due percorsi che potreste fare:

1. Sviluppa due applicazioni e accetta che siano applicazioni separate. (e forse anche cambiare il nome per la nuova applicazione) Ciò implica la divisione del codice di base. Ottieni i dati comuni in un back-end per servire i dati e quindi suddividere le applicazioni tramite un'API. Se esiste una comunanza reale, è possibile iniettare le parti comuni in entrambe le applicazioni, laddove applicabile, attraverso una libreria condivisa, ma alla fine ci saranno due applicazioni ciascuna con il proprio backlog e la base di codice.

2. Riporta le funzionalità nella piega dell'app principale e sviluppa l'applicazione principale come un'applicazione con "funzioni premium", quindi abilitala per i tuoi clienti con un meccanismo basato sulle attestazioni che consente queste funzioni extra. Potrebbe essere necessario riprogettare l'applicazione in modo da poter differenziare, il che può essere costoso. I vantaggi sono che puoi continuare a condividere codice comune.

Vorrei dire che consiglio vivamente l'approccio alla modularizzazione. Anche se più difficile da attuare, è un approccio più pulito e riutilizzabile. Un caso facile da fare con la gestione per il lavoro extra è che questi moduli possono essere rivenduti tra i clienti e alla fine tornare all'app "originale" migliorando il suo valore di mercato