Refactoring While Programming

Probabilmente l'osservazione fondamentale nel libro Rifattorro di Fowler è che si sta molto meglio separando le modifiche che influenzano il comportamento del codice dalle modifiche che non lo fanno. Quelli di quest'ultima categoria, chiamiamo "refactoring". Se si mescolano queste modifiche, si incasinano, quindi non farlo. Puoi passare da una modalità di codifica a una di refactoring, ma non entrambe contemporaneamente. Perché se ci provi, non saprai cosa hai sbagliato.

Se provi a introdurre una modifica che modifica il comportamento, e il comportamento non cambia: hai fatto qualcosa di sbagliato; rivederlo e risolverlo Magari tiralo indietro.

Se provi a introdurre un refactoring e il comportamento non lo modifica: hai fatto qualcosa di sbagliato; rivederlo e risolverlo Magari tiralo indietro.

Non puoi effettuare quella semplice valutazione se provi entrambe le modifiche contemporaneamente. Né puoi, se non hai test unitari. Scrivi a loro. E fai una cosa alla volta.

Ecco cosa faccio spesso: lasciati note come commenti o anche codice commentato. Quando hai funzionato il codice sciatto, ora puoi riorganizzarlo facilmente.

Inoltre, non c'è nulla di intrinsecamente sbagliato nel refactoring mentre procedi, ma assicurati di avere i modi per verificare che il codice refactored non introduca nuovi bug prima di procedere.

Un'altra buona regola è che ogni metodo dovrebbe fare solo una cosa.

Se interrompi l'elaborazione di ciò che stai cercando di implementare in piccoli passaggi discreti e codifica i passaggi come metodi, allora quando è il momento di ridimensionare, scoprirai che l'unico refactoring che ha senso è per cambiare l'ordine in cui sono chiamati i metodi o per lasciare alcuni metodi fuori dal percorso di esecuzione.

Inoltre, poiché i tuoi metodi sono discreti, sei libero di ridimensionare qualsiasi singolo metodo finché il valore restituito è quello che dovrebbe essere, nessun altro codice sarà più saggio di ciò che è stato fatto.

Questo ti consente di eseguire miglioramenti incrementali del tuo codice nel tempo semplicemente ottimizzando un metodo qua e là. La logica generale non cambia, solo i dettagli di un particolare passaggio.

Se segui questo metodo dai metodi alle classi, dove nelle tue classi fai o rappresenti solo un singolo oggetto, scoprirai che, proprio come con i metodi, il tuo refactoring diventa più semplicemente un rimpasto dell'ordine che le tue classi sono costruito e usato, e meno riguardo alla reale modifica della logica dei dettagli.

Sai di avere raggiunto il punto giusto quando le specifiche del programma cambiano drasticamente e improvvisamente, ma sei in grado di soddisfare quasi tutte le modifiche richieste semplicemente modificando le relazioni tra i tuoi oggetti - senza cambiare affatto la loro implementazione interna! Sembra che improvvisamente acquisisca il nirvana!

Buona fortuna e tutto il tuo codice può essere privo di bug!

Rodney

L'unità di test del codice potrebbe essere d'aiuto.

È possibile che tu stia scrivendo interfacce come se avessi un approccio dall'alto verso il basso per risolvere un problema, ma poi implementandolo dal basso verso l'alto? Se è così allora penso che sia il logico disaccordo che ti sta causando problemi.

In base a ciò che stai descrivendo potrebbe essere meglio rompere il problema in modo che tu possa pensare ad almeno una cosa che devi fare, quindi implementare proprio questo. Pensa a un'altra cosa che devi fare e attua solo questo. Continua, costruisci la tua soluzione in modo che tu scriva prima i fondamenti assoluti, poi i blocchi costitutivi che si basano su quelli e così via fino a quando non hai risolto la vera soluzione. Tendo a scoprire che la soluzione completa, anche a problemi difficili, tende a insidiarsi e saltare improvvisamente quando si segue questo tipo di approccio.

Se mantieni i blocchi intermedi logicamente focalizzati e mantieni deliberatamente ogni segmento di codice chiuso e limitato, allora la quantità di refactoring che devi fare deve essere sempre piccola e isolata.

... it is tempting to make a small update to my design, rather than erase what I've already written and write it the way it is supposed to be.

Nulla è supposto. L'unica cosa che si suppone è che:

1. puoi fare qualsiasi cosa che desideri
2. la tua vita / il tempo di lavoro è limitato e puoi raggiungere solo un numero limitato di cose.

Che cosa vuoi? Uno ha finito il progetto perfetto super-duper-excellent-clean-code, o tre progetti finiti, solo il 70% -code-elegancy rispetto al primo, ma 3 volte il 95% del punto di vista dell'utente? Cosa sarà più utile per il mondo, per la tua gente, per la tua missione?

Che cosa vuoi?

Naturalmente, a lungo termine, potrebbe ripagare il refactoring (abbassa il tempo di mtce ecc.), ma solo a lungo. Noi, i programmatori, siamo spesso tentati di refactoring e ottimizzare molto prima del necessario. Spesso rifattiamo un codice che non è ulteriormente sviluppato, il che significa tempo perso.

Io uso la mia regola d'oro della 2-3. Nel primo utilizzo di un particolare codice, mi basterebbe bastarlo al più presto. Non è quasi mai conveniente pensare a un uso più generale di questo, perché non si hanno ancora abbastanza informazioni su quali casi d'uso potrebbero arrivare. Inoltre, questa parte del codice potrebbe non essere mai più utilizzata. Quando il codice è necessario per la seconda volta, cerco di rendere il primo codice più generale da applicare anche a questo caso, o scelgo di copiarlo (ma questo non mi piace). Con il terzo utilizzo sento di avere abbastanza informazioni per refactoring e, visto che questa parte di codice sembra essere realmente utilizzata, sento che ripaga.

What results is a mess of code that needs to be refactored.

Soffia il problema fino a quando non lo capisci. Quindi esegui un'implementazione nuova e corretta dopo averne verificato la forma.

Per rispondere alla tua domanda in termini più generali: ricorda a te stesso che le modifiche necessarie in genere causano meno ripple / ripetizioni se effettuate prima o dopo.