Forse questo è in qualche modo utile per te, presenterò un modo in cui lavoro sul codice legacy. Ci sono molti altri come prima di estrarre i campi. Dipende, è diverso per ogni pezzo di codice legacy. Se non funziona la prima volta, torna indietro di un'ora (ripristina le modifiche), provalo un secondo e anche una terza volta, otterrai esperienza in tal senso, in base alle condizioni da cui iniziare in quel modo o in un altro.
Un modo di lavorare è:
- Nel primo passaggio dovresti classificare i metodi che hai, ad es. business, controller, dati, ui e ordinali all'interno della classe per raggrupparli. Se un metodo non può essere categorizzato correttamente, fa molto: estrai metodi più piccoli. categorizza anche questi metodi.
- Al secondo passaggio provo a ridurre le dipendenze dalla classe, da cui voglio spostare il codice. Hai categorizzato quei metodi incriminati e tutti questi metodi dovrebbero nel migliore dei casi non avere dipendenze dai campi o dai membri della classe. Questo può essere fatto introducendo parametri invece di usare campi di classe in firme di metodo. Il nuovo metodo risultante può essere potenzialmente spostato.
- Il terzo passo è creare una nuova classe a cui appartiene una delle categorie (in java sto usando inizialmente le classi interne e poi estrai l'intera classe in un file separato, quando tutte le dipendenze utilizzano un contratto pubblico) e per creare un'istanza della nuova classe nella classe da ripulire.
- Ora sposta il metodo più semplice (frutto appeso più basso) nella nuova classe e sostituisci l'invocazione con un'invocazione sul nuovo oggetto creato.
- Tutti questi refactoring hanno lo scopo di non causare differenze nell'ordine di esecuzione del runtime. Applicare solo quei refactoring. Prova a fare affidamento sul supporto IDE e ricontrolla ogni modifica, dato che non hai ancora test unitari. Quando esegui piccoli refactoring, puoi fermarti ogni volta che devi / devi - e consegnare il codice così com'è.
- Impegnati spesso. Intendo tutti uno o due minuti. Mantieni tutte le modifiche il meno possibile e non cercare di essere intelligente - nessun refactoring parallelo - uno dopo l'altro - scrivi una lista di passaggi verso il basso - non cercare di ricordarli tutti - tutto ciò che serve per disturbarti è una telefonata - e il tuo effetto è sprecato. Non refactoring 10 minuti senza commettere. Questi refactoring sono soggetti a errori. Il commit spesso consente di trovare la causa di un errore di refactoring, ad es. tramite ricerca binaria su commit.
- Ora creare test unitari per il singolo metodo estratto e spostato.
- Ora sposta il prossimo metodo di frutta in sospensione a una nuova classe, scrivi test ecc.
- se hai delle dipendenze rispetto alla classe precedente, rendi temporaneamente pubbliche queste dipendenze, annota / documentale, che questa non è l'API pubblica, ma è necessaria per il refactoring.
- ora controlla, se hai bisogno di interfacce ed estraile per ridurre le depenenze tra la precedente classe e la nuova classe estratta.
Questo passo dopo passo rimuove il codice in modo sicuro dalla classe. Ma non spostare le invocazioni all'interno del codice del metodo, funziona solo con / su metodi completi. (Otterrai le ottimizzazioni quando avrai più copertura di prova)
Ora hai i test unitari per i nuovi metodi estratti e il precedente codice di codice di classe è meno ingombrante. Ora sperimenterai più metodi che possono appartenere alla classe estratta anche. Poiché vedi, chi sta ora invocando la nuova classe estratta. Scrivi altri test.
Procedi con altre categorie. Se rimani bloccato, va bene, torna un'altra volta o dormi una notte sopra. Ciò migliorerà il codice passo dopo passo e nessun passaggio è costoso - solo da uno a due minuti. Quando ottieni più esperienza su questo, migliora i frutti più alti. Inizia con quelli pendenti più bassi. Prima di aggiungere una nuova funzione, provare a declutterare il codice, provare a identificare il codice che è necessario modificare e separarlo dal codice che non è necessario toccare. Quindi aggiungere nuovi metodi utilizzando una cucitura e scrivere test per loro.
Se vuoi un suggerimento su un libro da leggere - sul codice legacy: "Lavorare in modo efficace con il codice legacy" di Michael C. Feathers. Inoltre, non perdere l'ottimo video di YouTube "Praticità di refactoring" sul refactoring a piccoli passi. È in qualche modo l'apertura degli occhi. Ma non devi essere pienamente d'accordo con loro.
TL; DR: Bene, dopo averlo letto di nuovo, questo funziona prima su SRP (Single Responsibility Principle).
hth a bit.