Come far fronte a progetti molto simili

Naviga le tue risposte
3

Nella nostra azienda, gestiamo tre prodotti, che sono abbastanza simili, in 2 progetti.
Tutto Java, usando Maven per le dipendenze.

Questi tre prodotti si sono evoluti da un altro progetto, che ora è una dipendenza di entrambi i progetti.

Diciamolo in questo modo:

I progetti A e B sono così simili, che essenzialmente ogni correzione di bug per A deve essere copiata o unita per il progetto B.
I sapori del progetto B, d'altra parte, descrivono differenze molto distinte nel comportamento tra questi due. Ad esempio altri elementi in un menu del tasto destro. Questo è stato ottenuto da mostri brutti se-altrimenti-mostri, che sono in parte svaniti a favore di un approccio più OOP, ma ora portano ad un altro problema: dove organizzare queste classi dipendenti dal sapore?

Al momento, distribuiamo i nostri progetti con i profili per le diverse build di maven.

Il nostro obiettivo è unire entrambi i progetti (eventualmente anche con il progetto di base) in uno con sapori distinti.

La mia domanda ora è: come organizzarlo?
Il nostro approccio principale è quello di migliorare il Progetto B con le caratteristiche del Progetto A definendo un terzo gusto per il Progetto B e lasciare A gradualmente superfluo, in modo che le nostre correzioni di bug debbano essere fatte in un solo posto.
Quindi abbiamo immaginato la nostra struttura del progetto più o meno così: 

tld.company.project.<all of the logics with dependency injection> 
tld.company.project.flavor.<flavor 1>.<implementations>
tld.company.project.flavor.<flavor 2>.<implementations>
tld.company.project.flavor.<flavor 3>.<implementations>

All'interno della logica aziendale, dovremmo quindi iniettare un XyHandler , che è implementato in ogni sapore e verrà popolato dal nostro bean.xml

Questo sembra essere mantenibile? O anche desiderabile? Ogni idea è ben accetta!

Il codice base comune è così enorme, dobbiamo trovare un modo per combinare questi due progetti.

    
posta Phe0nix 01.06.2016 - 22:02
fonte

2 risposte

2

Il codice che è comune ad A e B deve essere spostato nel progetto di base. Se qualcosa viene lasciato in A dopo averlo fatto, spostalo in flavor 3. Quando hai finito B dovrebbe avere solo sapori in esso.

È davvero così semplice, a meno che non ci sia qualcosa che hai lasciato fuori. Ricorda, i progetti esistono per la separazione concettuale più di ogni altra cosa. Se avere più progetti è un problema, uniscili. Se li tieni, crea solo ciò che è per molto chiaro.

In alternativa puoi fare qualcosa a cui sono più abituato. Ogni prodotto ha il proprio progetto. Base diventa tutto comune.

Il vero trucco è convincere le persone a smettere di duplicare il lavoro tra i progetti. Scopri chi e perché questo sta accadendo e assicurati che si fermi.

    
risposta data 02.06.2016 - 04:27
fonte
2

Vorrei prendere in considerazione la definizione di un aroma da un file di configurazione piuttosto che da una collezione di interfacce.

Immagino che sia qualcosa del genere: 

features:
   - FOOBAR
   - GOATS
   - HOUSES
frobnosticator_mode: FLASHY
server_address: www.example.com
name: "Flavor Fantastic"
length_of_music: 2012
supports_cows: True

Ogni volta che il codice deve comportarsi in modo diverso per sapori diversi, dovrebbe leggere l'informazione rilevante dalla configurazione. Ad esempio, quando l'utente fa clic con il pulsante destro del mouse su un elemento, il codice decide quali elementi visualizzare nel menu a seconda delle funzionalità attivate. L'iniezione di dipendenza può iniettare un'implementazione diversa di Frobnosticator in base al valore di frobnosticator_mode . Quando l'utente tenta di importare una mucca, l'app può controllare la configurazione di supports_cow .

Ma perché?

  1. Le stesse informazioni possono essere utilizzate in più punti del tuo codice. Se due funzionalità dipendono dal fatto che una funzione sia abilitata, possono semplicemente leggere lo stesso valore di configurazione.
  2. Sarà più semplice abilitare la funzionalità in un sapore che esiste già in un altro gusto.
  3. Ogni pezzo di codice mostrerà chiaramente quali aspetti particolari di un sapore si preoccupa di quali valori di configurazione legge.
  4. Il codice sarà più facile da seguire se non è necessario saltare a una delle tre sottoclassi
  5. Applica la pressione per avere lo stesso codice ben collaudato in esecuzione in ogni aroma invece di un codice diverso, meno ben testato, in esecuzione ciascuno.
risposta data 02.06.2016 - 01:01
fonte

Leggi altre domande sui tag

Il BOM è opzionale per UTF-16 e UTF-32? Come dovrei interrogare il DB per una chiave specifica senza interrogare ogni volta che viene chiamata la funzione?