La riorganizzazione di un progetto di espansione e il riuso

Question

Lo scopo del progetto a cui sto lavorando è in fase di ampliamento.L'applicazione è abbastanza semplice, ma attualmente gli obiettivi di una nicchia molto specifica.Per l'immediato futuro, mi è stato chiesto di fare un fork del progetto al raggiungimento di un nuovo mercato e di continuare a sviluppare due progetti in tandem.

Entrambi i progetti saranno funzionalmente simili, quindi non c'è un incentivo molto forte per generalizzare un sacco di budella del progetto originale.Inoltre sono certo che sarò di targeting più mercati nel prossimo futuro (i mercati geografici).

Il problema è un precedente manutentori del progetto hanno fatto un sacco di ipotesi che legame c'e ' mercato.Sta andando a prendere un po ' di refactoring per separare il generico dal mercato specifico codice.

Per rendere le cose più complesse molti suggerimenti sono stati gettati in giro su come organizzare i progetti per il crescente numero di mercati:

1. Ogni mercato è un progetto separato, comunanze tra i progetti che si sono spostati in una libreria condivisa, i progetti sono distribuiti in modo indipendente.
2. Espandere il progetto esistente a destinazione più mercati, limitando la funzionalità basata su licenza acquistata.
3. Creare un genitore applicazione e riprogettazione progetti come plug-in, acquistato separatamente

Tutte e tre le proposte sono di merito e, idealmente, vorrei strutturare il codeto essere abbastanza flessibile che uno di questi è possibile con piccoli aggiustamenti.Suggerimento 3 sembra essere il più scoraggiante come richiederebbe la costruzione di una architettura a plugin.I primi due suggerimenti sono un po ' più plausibile.

Ci sono buone risorse disponibili sui pro e i contro di queste architetture diverse?

Quali sono i pro e i contro sulla condivisione di codice tra i progetti versi di copia e di fare un fork?

Answer 1

La deviazione è di solito andando a ottenere un risultato più veloce all'inizio, ma quasi sempre andando a venire intorno e mordere in manutenzione -- correzioni di bug e miglioramenti delle funzionalità da una forcella perdersi in altre forcelle, e alla fine ti ritrovi a buttare fuori tutta la forcella e dover ri-aggiungere le loro caratteristiche, la "migliore" della forcella.Evitare se possibile.

Avanti:tutte e tre le opzioni possono lavorare, ma hanno trade-off in termini di complessità di realizzazione, costi di manutenzione, la distribuzione, la comunicazione, il sovraccarico e la quantità di refactoring che devi fare.

---

1.Ogni mercato è un progetto separato

Una buona soluzione se si sta andando ad essere in via di sviluppo contemporaneamente per più mercati.

Pro:

• Esso consente agli sviluppatori per il mercato A rompere A costruire, senza interferire con i lavori in corso sulla B
• Rende molto meno probabile che un cambiamento per il mercato A causa di un bug per il mercato di B

Contro:

• È necessario prendere il tempo per separare il codice condiviso
• È necessario prendere il tempo per impostare parallelo costruisce
• Modifiche al codice condiviso ora hanno costi superiori in quanto influenzano entrambe le squadre.

2.Espandere il progetto esistente a destinazione più mercati

Può essere fatto funzionare bene per un bel po'.Se avete intenzione di essere al lavoro su versioni per il mercato in un momento, con un piccolo team, potrebbe essere la vostra scommessa migliore.

Pro:

• La licenza di lavoro è probabilmente prezioso in ogni caso, anche se si sposta verso (1) o (3).
• L'unica base di codice permette di refactoring in tutti i mercati.

Contro:

• Anche se stai lavorando su qualcosa per il mercato a, è necessario costruire e spedire il codice per i mercati B, C e D, come pure-bene se si dispone di una piccola base di codice, ma sempre più fastidioso, come si ottiene in migliaia di classi di
• Le modifiche apportate a un rischio di mercato il rischio di rompere il codice per altri mercati
• Le modifiche apportate a un mercato richiedono altri mercati e ri-testato

3.Creare un genitore applicazione e riprogettazione progetti come plugin

Si sente tecnicamente dolce, e può consentire di condividere il codice più.

Pro:

• Tutti i pro (1), potenzialmente, di più:
  • chiara separazione del condivisi e specifici del mercato del codice
  • può consentire di muoversi verso una API pubblica, che avrebbe consentito delegare alcuni il lavoro su clienti e/o vendita di lucrosi progetti di servizio

Contro:

• Tutti gli svantaggi di (1), plus richiede anche più di refactoring.

---

Credo che (2) è una sorta di dove vi trovate ora, a parte le licenze.Penso che va bene a rimanere lì per un po', ma mettere qualche sforzo in movimento verso (1) -- spostando il codice condiviso in un progetto separato, anche se tutto costruito insieme, per esempio, cercando di assicurarsi che le dipendenze dal mercato del codice a codice condiviso sono tutti a senso unico.

Se si finisce a (1) o (3) tipo di dipende.Per lo più si tratta di chi è "in carica" -- codice condiviso, o il mercato di codice specifico?La linea tra un plugin, e una classe controller, che consente di configurare alcune componenti condivisi, può essere piuttosto sfocata.Il mio consiglio sarebbe, lasciare che il codice di dirvi che cosa ha bisogno.

Answer 2

1) NO! Se non si desidera gestire diversi rami della stessa base di codice ... Perché così comune come il codice può essere, si vuole fare cambiamenti radicali, e un progetto sarà "al momento" non essere così importante come gli altri , e quindi si otterrà un ramo cresce più velocemente rispetto agli altri .... inserto a palle di neve.

2) Questo è più o meno lo standard del settore. Big file di configurazione, limita le cose sulla base di licenza / configurazione. Si può fare l'applicazione un po 'ingombrante, ma fino a quando il codice si lamenta roba circa escludono a vicenda e tutti gli sviluppatori sono in costante comunicazione sulle nuove funzionalità e il modo in cui si propagano in tutta l'applicazione, si dovrebbe fare bene. Questo è anche il più facile da hackerare, se questo è un problema.

3) Questo anche 'puo' lavoro. Se si sta utilizzando C #, i plugin sono relativamente semplici, si deve solo preoccuparsi di inferno delle dipendenze. Se i plugin hanno alcuna possibilità di diventare interdipendenti circolarmente (cioè un richiede b richiede C richiede a), allora questo esploderà in fretta e si ritornerà (abbastanza facilmente) torna alla # 2.

Le migliori risorse disponibili sono probabilmente le esperienze passate dei vostri colleghi su diversi progetti, e l'esperienza delle persone yammering su di esso qui o Slashdot o dovunque. Certamente il più conveniente.

A favore di condivisione di codice: Un cambiamento cambia tutto. modello di dati unificato. C'è una sola verità. (Molto più facile per tutti di essere sulla stessa pagina)

Contro di condivisione di codice: Un cambiamento cambia tutto .. Fate attenzione. Se un bug è in esso, colpisce tutto.

A favore di copia / biforcazione: Di solito più veloce per implementare una funzionalità specifica per un determinato cliente. Più veloce di hack, quando ti rendi conto che ipotesi A è applicabile solo per i mercati B e C, non D.

Contro di copia / biforcazione: Uno o più dei progetti copiati finirà per fallire, a causa di una mancanza di coesione nel codice. Come sopra detto: cambiamenti radicali prendono molto più tempo

.

In bocca al lupo.

Answer 3

Hai detto "copia e si biforcano", che mi porta a pensare che forse non hanno considerato la gestione di questa "forchetta", come un ramo in un sistema di controllo di revisione, come SVN. Facendo in questo modo, quando si refactoring il ramo per accogliere un settore diverso, è possibile unire i cambiamenti nel tronco principale con l'ausilio del sistema di controllo di revisione.

Se si sta seguendo una strategia a lungo termine di trasferirsi in una singola applicazione in cui tutte le variazioni sono controllati da un file di configurazione (o un database di configurazione SQLITE) allora questo approccio vi aiuterà. Non è necessario fondere nulla fino a quando si è sicuri che si è generalizzata per entrambi i settori, in modo da poter ancora costruire due sistemi unici finché è necessario. Ma, non esegue il backup se stessi in un angolo, perché è tutto in un unico albero di codice sorgente, il tronco per l'industria legacy, e un ramo per ogni nuova industria.

Se la vostra azienda vuole davvero atack diversi settori, quindi non credo che la soluzione database di configurazione soddisferà tutte le vostre esigenze. Sarà ancora bisogno di avere moduli di codice speciali di qualche tipo. Un'architettura plug-in è una buona cosa da mettere in, perché vi aiuterà, in particolare se si incorpora un motore di scripting come Python nella vostra app. Tuttavia, non credo che i plugin saranno in grado di soddisfare tutte le vostre esigenze di variazione di codice quando si entra in "migliaia di classi" scala.

È necessario adottare un approccio pragmatico che permette di costruire un'applicazione separata oggi per la nuova industria, ma rende relativamente facile per unire i miglioramenti in app esistente come si va avanti. Si può mai raggiungere il nirvana di un unico tronco con migliaia di classi e diverse industrie, ma avrete almeno hai addomesticato la complessità, e avrà solo a che fare con veramente importanti variazioni in cui v'è reale divergenza nella necessità dell'industria.

Se fossi nei tuoi panni, vorrei anche essere guardando ogni e tutte le caratteristiche in app che possano essere considerati "reporting" e cercando di fattore fuori, forse anche in un off lo strumento di reporting mensola.