Pratiche architettoniche / applicative per evitare "rotture di modifiche"

Question

Pratiche architettoniche / applicative per evitare "rotture di modifiche"

#1 da (4 voti)
#2 da (-1 voti)

5

Abbiamo un'applicazione in cui il cliente ha cambiato idea su una vasta area di funzionalità e quest'area richiede una grande quantità di rielaborazione.

Sebbene la rilavorazione in sé non sia un problema, ha introdotto una situazione in cui l'impatto dei cambiamenti è ampio e comprende:

Dati
Query Logic / Struttura tabella
Logica aziendale
Display / Presentazione

Idealmente vorremmo incorporare questi cambiamenti contemporaneamente a molti altri flussi di sviluppo, ma siamo preoccupati che l'impatto dei cambiamenti avrà un impatto negativo sulla frequenza con cui possiamo fornire. Siamo in grado di provvedere ad alcuni di questi attraverso i rami, ma mi ha fatto chiedere quali sono le possibilità per proteggersi da questo tipo di cose dal punto di vista dell'architettura applicativa o della pratica di sviluppo.

Le cose che facciamo attualmente:

Logica di query astratta nei repository: è ideale per piccole modifiche, ma quando la logica generale in un'area cambia, ad es. invece di ottenere un elenco di utenti che soddisfano determinati criteri, dobbiamo ora ottenere un elenco di organizzazioni che hanno aderito alle posizioni.
Logica aziendale astratta in servizi - Questo è esattamente lo stesso dei repository in quanto non possiamo davvero evitare interi cambi logici, ma piccole modifiche possono essere accolte con un impatto limitato.
Assicurati che la configurazione sia fuori dal codice che richiede una nuova distribuzione, una combinazione di righe del database o valori di web.config.
Altri modelli che promuovono aspetti di flessibilità come le fabbriche, ove opportuno, ecc.
Feature flag per la selezione della funzionalità se originariamente venivano sviluppati due approcci. etc

Esistono altre best practice attuali per proteggersi dai cambiamenti, senza incorporare i rami ecc.

architecture maintainability changes

posta dougajmcdonald 21.01.2015 - 15:06

fonte

2 risposte

Leggi altre domande sui tag architecture maintainability changes

Usando Facebook per autenticarsi, come collegarmi al record utente nella mia app? E-mail? Come accedere a grandi quantità di dati per l'apprendimento automatico in un'architettura di microservizi

score 4 · Answer 1

L'unica cosa che puoi fare per contribuire a ridurre l'impatto di un cambiamento è suddividere il tuo progetto generale in molti componenti, quindi mentre un cambiamento importante avrà un impatto su molti di essi, molti non ne risentiranno.

Ad esempio, se il cliente decide che è necessario un nuovo pulsante che invii i dati attraverso il middletier per essere memorizzati in una nuova colonna nel DB, dovrai cambiare ogni livello del tuo sistema. Tuttavia, se anche il sistema è suddiviso "orizzontalmente", l'impatto dell'interfaccia utente riguarderà solo parte del livello dell'interfaccia utente, il resto non verrà modificato. Allo stesso modo, se nel tuo middle tier hai molti servizi che ognuno processa determinate parti dei dati, dovrai cambiarne solo una - il resto non sarà influenzato. anche il DB può essere partizionato in schemi indipendenti.

Quindi, ad esempio, è necessario ottenere un elenco di utenti, in modo da disporre di un servizio che gestisca i dati dell'utente. Quando hai bisogno di ottenere anche un elenco di organizzazioni, aggiungi un nuovo servizio che si occupa di questo e unisci i dati nell'interfaccia utente (ad esempio), il che significa che non hai affatto dovuto modificare il tuo codice di accesso dell'utente. Penso che questo tipo di approccio sia definito microservizi , anche se ovviamente "micro" non deve significare minuscolo, solo logicamente separati .

Non proverei a introdurre astrazioni in quanto tutto ciò che accadrà è che legheranno i tuoi strati (ad esempio una modifica DB richiederà ancora la modifica della tabella sottostante, ma ora anche il layer DAL wrapping avrà bisogno di modifiche e avrà un DAL non ti consentirà necessariamente di dividere il DB in sezioni, a meno che tu non entri in una complessità molto maggiore.

score -1 · Answer 2

Test unitari e test di integrazione possono essere utilizzati per proteggere la logica dalle modifiche al codice.

Se attualmente disponi di una buona copertura del codice e devi rielaborare una sezione, l'approccio sarebbe più semplice, puoi cambiare i test per riflettere il risultato dopo la rilavorazione e una volta che hai fatto il cambiamento è possibile ri-eseguire i casi di test, per assicurarsi che tutto funzioni. (In pratica sarebbe una buona idea usare un server di integrazione continua per eseguire test dopo ogni commit, e con questo si possono fare piccole modifiche alla volta e assicurarsi che tutta la logica sia intatta con lo stato del server CI)
Se non hai test, sarebbe una buona idea crearne alcuni. Se sei in una scadenza ristretta, potresti iniziare con i test di integrazione in cui i test verificheranno l'output dell'input dato dal livello di presentazione. Per ogni luogo in cui è necessaria una modifica, è possibile iniziare con la creazione di test per l'output previsto dopo le modifiche, quindi apportare le modifiche e accertarsi che i test siano verdi.