Le migliori pratiche per mantenere i modelli precedenti nel codice?

Question

Le migliori pratiche per mantenere i modelli precedenti nel codice?

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

3

Durante il mio primo seminario di part-time durante il college, mi sono occupato di un'applicazione web di grandi dimensioni responsabile della gestione di un evento periodico ospitato dal nostro cliente, in gran parte un semplice snoozefest CRUD con un numero di moduli da compilare per gli utenti .

Le forme cambiano tra gli eventi, con la maggior parte delle forme con una piccola quantità di modifiche apportate a loro - alcuni campi aggiunti, rimossi e adattati, ad es. una domanda aperta divisa in due o una scelta cambiata da radio a caselle di controllo. Tutti i moduli delle edizioni precedenti devono essere accessibili in ogni momento.

Il codice è diventato rapidamente pieno di classi base come:

veryImportantFormModel
veryImportantFormModelLegacy
veryImportantFormModel2017

costituito principalmente da codice incollato su copia in molti strati del backend e del frontend. Quale per i miei occhi inesperti di sviluppatori junior sembra un modo rapido per accumulare quantità ingestibili di debito, e speriamo che non sia la soluzione ideale per quello che presumo sia uno scenario molto comune.

Quale sarebbe un modo più sano di fare le cose?

object-oriented-design

posta j4nw 02.03.2018 - 11:58

fonte

2 risposte

4

Se tutte quelle vecchie edizioni devono essere mantenute dal vivo, penso che la tua migliore fotografia sia

isola le classi che appartengono all'evento specifico
inseriscili in uno spazio dei nomi che indica l'evento specifico e la data o il mese in cui si verifica

(ovviamente, il tuo ambiente e il linguaggio di programmazione supportano gli spazi dei nomi, presumo?).

Quindi puoi avere tutte le versioni di veryImportantFormModel che desideri live in parallelo, ognuna delle quali vive in uno spazio dei nomi diverso.

Nota che questo tipo di ufficio tecnico è gestibile quando ci sono molte probabilità che non devi toccare il codice precedente per gli eventi in cui è accaduto in passato. La manutenzione è solo un problema per il codice che deve essere mantenuto attivamente, non per il codice che è solo "in esecuzione".

Questo è molto simile alla situazione in cui si ha un prodotto con versioni 1.0, 2.0, 3.0 e 4.0, ognuna basata sulla precedente e ognuna delle quattro distribuita e in uso in parallelo. Quando inizi a sviluppare la versione 4.0, potresti avere l'obbligo di eseguire una manutenzione minima sulla riga 3.x e forse hai bisogno di distribuire le versioni 3.1 e 3.2. Tuttavia, quando la versione 4.0 diventa attiva, la richiesta di emissione per le righe precedenti generalmente scenderà e le nuove funzionalità verranno aggiunte alla versione più recente. In una situazione basata sul contratto, puoi anche rendere questo modello parte del contratto.

risposta data 02.03.2018 - 14:46

fonte

Leggi altre domande sui tag object-oriented-design

Autonomia dei microservizi Informare gli utenti di bug in sospeso

score 3 · Accepted Answer

La cosa fondamentale che spicca per me è:

"All forms from previous editions must be accessible at all times."

Immagino tu intenda vivere nell'applicazione? Se è così, allora sì, avrai bisogno di tutti quei file, l'unica cosa che puoi fare è fare una convenzione di denominazione e metterli in versione. Spingi con impegno i vecchi moduli di disattivazione, se possibile.

Resisterei all'impulso di rifattenerli in una gerarchia ereditaria. Sebbene OOP possa sembrare suggerire che questa è la strada da percorrere, il problema è che queste modifiche non sono guidate da un caso aziendale noto, ma dall'evoluzione dei requisiti.

In queste condizioni, potresti potenzialmente dover refactoring enormi quantità di codice se si collegano le versioni insieme per ereditarietà e qualche pazzo cambiamento inaspettato arriva.

Se riesci a mettere in discussione il requisito che tutti i moduli siano disponibili, allora direi che la pratica migliore è avere un percorso di migrazione per gli oggetti.

Puoi conservare solo la versione più recente del modulo e migrare i vecchi dati per adattarli.

Modifica: come proporre la rimozione delle autorizzazioni in modo intuitivo.

Questo è difficile perché mantenere i moduli è un problema per te e non per il client.

Direi che l'approccio migliore è valutare il costo di mantenere più moduli e includerlo nel costo del software.

Questo rende il problema dei clienti, puoi quindi dire. "Possiamo darti un prezzo più basso se non dobbiamo supportare quei vecchi moduli."

Tuttavia, devi essere onesto con te stesso sul costo della manutenzione. È probabile che ti stia pagando solo lo spazio su disco. Tieni traccia dei bug che puoi risalire a causa dei vecchi moduli e il tempo impiegato per testare i vecchi moduli quando si apportano modifiche.