costruzione versione software dipendente dalla versione

Crea solo un'applicazione con interruttori on / off per varie funzioni. Sviluppare e mantenere un'applicazione è molto più semplice rispetto a fare lo stesso con due app. Puoi pensare che non sarà un grosso problema dato che due applicazioni saranno molto simili, quindi ci sarà un sacco di riutilizzo del codice e come vantaggio avrai due applicazioni, ognuna sarà più semplice a causa della mancanza di interruttori ( che spesso aumentano significativamente la complessità). Ma le basi di codice alla fine divergono (se non si presta estrema attenzione) e il riutilizzo del codice diventerà sempre più difficile.

Detto questo, potrebbero esserci casi in cui due app separate sono migliori:

La scalabilità
• non è la stessa cosa delle prestazioni. Un'applicazione più scalabile può essere più lenta (anche significativamente) rispetto a quella non scalabile su dataset più piccoli.
• scalabilità e / o altre funzionalità possono complicare l'implementazione / gestione dell'applicazione. Ad esempio, un'applicazione scalabile potrebbe richiedere un database esterno che può essere facilmente ridimensionato. Non scalabile può essere sufficiente con un solo database interno che non deve essere implementato / gestito separatamente
• più funzionalità spesso significano anche un'interfaccia utente più "scalabile". Questo potrebbe complicare l'utilizzo dell'applicazione leggera perché ha ancora l'interfaccia che è destinata a supportare le funzionalità extra, solo senza quelle funzionalità extra.
Gli switch
• per varie funzionalità aumentano notevolmente la complessità del progetto - ora è fondamentalmente necessario testare le versioni 2 ^ (numero di switch) dell'applicazione. Questa complessità potrebbe essere troppo grande per essere gestita e avere due applicazioni separate potrebbe essere più semplice. Questo è comunque un caso estremo.

Spesso puoi prendere una via di mezzo: esternalizzare le differenze in un modulo separato che estrae le differenze (fondamentalmente il modello di strategia). Ad esempio è possibile moduli con core scalabile e core non scalabile che hanno entrambi la stessa interfaccia e possono essere scambiati a piacere. Un altro esempio è che è possibile avere diversi frontend (interfacce utente) che funzionano con lo stesso core di elaborazione, ciascun frontend ottimizzato per diversi casi d'uso (versione light vs versione heavy feature).

Due versioni della stessa cosa devono essere evitate a tutti i costi. Costruisci una cosa che può essere configurata per nascondere alcune finestre / menu / funzionalità. L'alternativa è molto costosa.

Supponiamo che tu costruisca due versioni. Entrambe le versioni devono essere scritte, test scritti per, testati manualmente. Correzioni di bug in entrambe le versioni. Entrambe le versioni devono essere mantenute.

In alternativa puoi creare una versione. Quindi crei una logica per disattivare alcune funzionalità. Quindi rispetto a quello che ho elencato sopra, una piccola logica per disattivare le funzionalità è chiaramente più economica. Inoltre, hai il vantaggio che quando una funzionalità è implementata puoi accenderla gratuitamente nella versione "light" se lo desideri.

Nel tuo specifico caso d'uso, perché non implementare un "limite" sui set di dati e addebitare ai clienti le dimensioni del set di dati? Dopo aver esaminato x record o x Gb il software si blocca o mostra qualche orribile popup o avviso sulle prestazioni o qualsiasi altra cosa fino a quando non si aggiorna.

Sarebbe abbastanza facile mantenere lo stesso codice base per le due versioni e si può facilmente dividere in più versioni se / quando necessario.

I sistemi di determinazione dei prezzi sono completamente un'altra bestia, ma per quanto riguarda il modo migliore per integrare la scalabilità sul tuo sistema di prezzi, ti suggerisco di fare in modo che il tuo sistema di prezzi misuri la scalabilità invece di limitarti a nasconderlo.

Voglio dire che hai due scelte, una delle quali sta avendo entrambi gli algoritmi in un posto e un altro che li ha come software separato (versione light, versione pro ecc.).

Per quanto riguarda il primo caso, non avrai molta flessibilità sul prezzo perché molto probabilmente costerebbe molto perché include l'implementazione scalabile.

In secondo luogo, la scelta è qualcosa che ho usato abbastanza spesso durante lo sviluppo di plugin per WordPress / software di marketing.

Il modo di combattere la duplicazione del codice dato che avrai inevitabilmente bisogno di scrivere librerie condivise.

Ad esempio:

Se stai facendo il tuo progetto in .NET e pensi che i tuoi moduli WPF sembreranno esattamente uguali, allora incapsuleranno quelli in un progetto condiviso e farà riferimento a entrambe le tue versioni.

Se stai facendo il tuo progetto usando JQuery, prova a usare plugin condivisi tra i due progetti.

E così via con altri linguaggi di programmazione / scripting.

In questo modo, se hai deciso di aggiungere una funzione che pensi appartenga ad entrambe, la avrai nel progetto condiviso, altrimenti scrivila specificatamente per la versione che desideri.

In questo modo avrai una buona separazione e combatterai anche la duplicazione del codice lungo la strada.