Condivisione di codice comune durante la riscrittura di un'applicazione

Question

Condivisione di codice comune durante la riscrittura di un'applicazione

#1 da (3 voti)

1

Ho un'applicazione 'A' che è stata sovrascritta usando Amazon SWF per fare lavori in modo asincrono. Lo stiamo riscrivendo nell'app "B" per mantenerlo semplice e fare gli stessi lavori in modo sincrono senza utilizzare SWF. Il codice effettivo che fa il lavoro è stato tenuto pulito e separato. L'applicazione "A" alla fine verrà disattivata, ad esempio tra un anno o due.

Sto pensando di evitare la duplicazione del codice mentre sviluppiamo "B". Potrei pensare

Creazione di una libreria comune

Pro:

Ogni nuovo codice aggiunto per l'app "A" verrà inserito anche in "B".
Il codice non è duplicato.

Contro:

Poiché l'app 'A' è stabile, la modifica del codice da separare in una libreria può essere complessa, richiede uno sforzo (che potrebbe non fornire sufficienti ritorni) e possono essere introdotti errori.
Nessuna altra app utilizza la libreria dopo che "A" è stato ritirato e in quel momento non ha senso avere una libreria.

Live con duplicazione del codice

Pro:

La nuova app può essere progettata come richiesto senza fronzoli.
Nessuna gestione della libreria non necessaria.
L'app 'A' sarà stabile.
Meno sforzi.

Contro:

Duplicazione codice

Qual è il modo migliore per farlo?

design refactoring design-patterns

posta TechCrunch 11.11.2017 - 00:43

fonte

1 risposta

Leggi altre domande sui tag design refactoring design-patterns

Livello aziendale nel sistema logico del database Qual è la differenza tra AUTOSAR e DDS?

score 3 · Answer 1

Ciò dipende in ultima analisi dalla complessità della logica dell'applicazione e dal livello di impegno e dal periodo di tempo per la disattivazione della "A".

Parliamo prima di quest'ultimo. Se esiste la possibilità che la disattivazione di "A" venga posticipata / posticipata per molti anni o se alla tua organizzazione o ai tuoi successori manchi la forza di volontà / motivazione per farlo, non dovresti duplicare il codice. Dovresti invece concentrarti sul refactoring di "A" per affrontare problemi specifici (a meno che, naturalmente, il codice sia irrimediabilmente cattivo e meriti di morire, nel qual caso dovresti assicurarti che "A" alla fine venga messo fuori servizio).

Ora una parola sulla complessità. La disattivazione della "A" può essere un compito arduo e potresti voler gettare una strategia concreta per farlo prima di imbarcarti nella costruzione di "B". Se non lo fai durante la disattivazione, rischi di imbattersi in un caso di utilizzo / funzione che solo "A" può supportare e "B" non può [facilmente] a causa delle decisioni di progettazione prese per "B". Questo è particolarmente importante se progetti "B" senza fronzoli (che nella mia esperienza rischia sempre di perdere un comportamento sottile).

Vorrei anche avvertire sulla creazione di una libreria condivisa. Se alla fine si finisce per mantenere entrambi "A" e "B" si potrebbe incontrare un sacco di problemi con l'approccio della libreria.

Le librerie condivise possono rappresentare un enorme problema di versioning. Per un semplice esempio, si consideri il caso in cui "A" è in esecuzione su Java 6 mentre "B" è in fase di sviluppo con Java 8. La libreria condivisa sarà forzata ad essere in Java 6 (fine vita nel modello di supporto premium). Trasporterai questo rischio? Anche se sei felice di vivere con quello, e se ci fosse qualche comportamento in questa libreria che funziona in modo diverso in base al tempo di esecuzione (Java 6 vs Java 8)? Dove emanerai la correzione? Problemi simili saranno presenti anche in applicazioni non Java.

Non sto dicendo che dovresti copiare / incollare il codice per evitare questa complessità, ma devi solo esserne consapevole in modo da poterlo pianificare.