Speriamo che questa domanda non sia troppo aperta ...
Mi è stato affidato l'incarico di acquisire un'applicazione di 3 anni (.NET 4.0, WPF, WCF, EF 4, SQL 2008) progettata per un mercato X molto specifico e "ripubblicata" per un altro molto specifico mercato Y.
Per complicare ulteriormente le cose, la società ha menzionato anche un terzo mercato Z, ma potrebbe essere un anno + lungo la strada. Ma sicuramente sta arrivando.
La scadenza per ottenere l'applicazione Y pronta per il mercato è aggressiva. Potrebbe essere negoziabile, ma supponiamo che si tratti di 2-3 mesi.
Lavoro in azienda da un po 'di tempo e sono stato intimamente coinvolto nella creazione iniziale dell'applicazione X, e sono ancora coinvolto nella manutenzione.
La nuova "applicazione" Y è interessante perché c'è una "sovrapposizione" tra le funzionalità richieste per X e Y.
Ad esempio, lasciate A, B, C, D ed E come feature e lasciate "(primo) denota un miglioramento di una funzione. Tutti i seguenti scenari sono validi:
---X---|---Y--- … ---Z--- (down the road)
A | A
B | B’
C’ | C
| D
E |
Alcune funzioni possono essere unite da X a Y come-è (A). Alcune funzionalità di X devono essere migliorate prima di poter essere unite in Y (B). Alcune funzioni di X non saranno in Y affatto (E), e Y conterrà caratteristiche che non sono in X (D). Hai un'idea.
Ecco le mie domande:
(1) Agli occhi del management superiore, alla fine vedono 3 diverse applicazioni - una per ogni mercato: X, Y, Z. Inoltre, vedono 3 diverse copie della stessa caratteristica A che dovrà essere inserita in ciascuna applicazione. Come discusso, potrebbero esserci alcuni miglioramenti che consentiranno di selezionare i prodotti, ma in sostanza sono quasi identici.
A volte sono colpevole di aver trovato delle scuse per usare le ultime tendenze di programmazione, ma credo che qui ci sia un strong business case per l'utilizzo del Managed Extensibility Framework (MEF). Perché avere 3 diverse applicazioni fisiche (e quindi 3 basi di codice) quando potrebbe davvero essere una "prossima generazione" con funzionalità plug-in attraverso qualcosa come MEF? Ci sono molti vantaggi che qualcosa come MEF potrebbe portare in tavola.
Una soluzione di estensibilità come MEF sembra valida in un caso come questo?
(2) Dato il tempo limitato per ottenere l'applicazione Y sul mercato ...
(a) Devo andare con un approccio conservativo e dare semplicemente alla gestione ciò che stanno chiedendo, cioè fare una copia profonda di X e modificarla per Y? Forse ci sarà tempo dopo che Y sarà sul mercato per sviluppare una soluzione più ideale ed estensibile? La mia esperienza passata con questa azienda ha visto le demo diventare prodotti a tutti gli effetti in pochissimo tempo - se ne hai la possibilità;)
Potrebbe essere molto più difficile modificare il codice X per farlo funzionare per Y piuttosto che per creare Y da zero e importare le funzionalità di X.
(b) Lasciando X da solo per ora, dovrei creare Y con MEF in mente. Le funzionalità di X possono essere facilmente importate in Y. Se ciò viene eseguito correttamente, Z dovrebbe essere facile da implementare. Sarà probabilmente un'impresa rischiosa tornare indietro e rivolgersi a X per inserirsi in questo quadro poiché è così ampiamente utilizzato, ma potrebbe essere fatto sul lato senza una scadenza specifica.
Devo dirlo al superiore. Qualche consiglio o pensieri?