Che cosa pensi fino a che punto un programmatore dovrebbe refactoring il codice?
Fondamentalmente con
def method do_something end
I codici potrebbero essere utili, ma aumentano il codice degli spaghetti fino al punto in cui devi ricordare il percorso di oltre 8-10 metodi. Quindi non sarebbe più facile avere non più di 3 metodi spaghetti code, nonostante il fatto che il metodo sia più lungo di quanto supponga essere
Il refactoring per me è principalmente per (1) ridurre la duplicazione del codice e (2) rendere il codice più facile da leggere e capire.
Cerca di avere zero (o ragionevolmente vicino allo zero) duplicati. Questo è il primo passo. Il secondo passo è quello di mantenere il refactoring finché non si ritiene che il codice sia sufficientemente leggibile.
Ad esempio, sostituire i commenti con i metodi è spesso un buon candidato per il refactoring, come questo:
// Is order valid for purchase?
if (order.age < 10 && order.customer.isActive()) {
// ...
}
Potrebbe essere refactored in:
if (isOrderValidForPurchase(order) {
// ...
}
Solo refactor quando c'è un bisogno assoluto di farlo - il refactoring è un po 'un odore, in teoria non dovresti aver bisogno di refactoring, il tuo codice dovrebbe essere buono fin dall'inizio come lo hai progettato bene ... ma, naturalmente, in pratica non è sempre così. Tuttavia, dovresti scrivere un codice che pensi sia buono sin dall'inizio, cercando di raggiungere questa perfezione impossibile.
Se rifattori continuamente, rimescolerai semplicemente il codice esistente per sempre, mai soddisfatto. Passerai tutto il tempo a refactoring e non aggiungerai mai nuove funzionalità, ti mancherà il punto di codice, che non è quello di scrivere un codice piacevole, ma di creare un buon prodotto.
L'altro problema con il refactoring è che si può finire con il refactoring nel tipo di codice che nessun altro potrebbe amare, diventando così preso dalla necessità di refactoring che si scopre manutenibilità. Il tuo esempio di metodi di refactoring su 1 riga potrebbe finire con un milione di minuscoli metodi se lo portassi all'estremo, e preoccuparti di quanto refactoring stai facendo suggerisce che stai già andando lungo il percorso di essere troppo preso in esso .
Secondo Martin Fowler, il refactoring è
"A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior."
Martin Fowler. Refactoring: Improving the Design of Existing Code. Boston, MA: Addison-Wesley, 2000.
Ciò significa che spetta principalmente a te e al tuo team decidere per la granularità dei metodi (lunghezza del metodo rispetto al numero di metodi). L'obiettivo principale è generare un codice che sia facile da capire ed economico da modificare.
Alcuni autori tendono a esagerare con il bisogno di refactoring. Per esempio. Unkle Bob fornisce alcuni esempi nel suo libro Clean Code, che sono assolutamente illeggibili secondo me. Sta seguendo le sue stesse guide in modo così rigoroso da non lasciare spazio a compromessi.
Se tre metodi più lunghi sono più facili da capire e meno costosi da modificare, attenersi ad esso.
Penso che quello con cui stai combattendo sia la nozione di coesione.
La coesione è facile da definire e difficile da capire. È l'idea che le cose che appartengono insieme dovrebbero essere vicine l'una all'altra.
Gran parte del refactoring sta rimuovendo la duplicazione. Questo generalmente porta al codice di disaccoppiamento, che può anche ridurre la coesione.
Un'analogia decente è l'idea che la coesione è come la colla, le parti realmente resistono all'essere separate perché sono parte integrante della struttura nel suo insieme. L'accoppiamento è come le viti, ti consente di mettere insieme due oggetti molto diversi, e quegli oggetti non resistono alla separazione (con un cacciavite).
La manutenzione / leggibilità è davvero il più grande driver in questa conversazione - qualcosa che non ha MAI bisogno di cambiare può essere strettamente intrecciata in qualcos'altro - a chi importa? Ma il fatto che tu abbia iniziato a refactoring significa quasi sempre che hai cambiato o che stavi cercando di cambiare questo codice. Quali cambiamenti renderà più facile cambiare in futuro? Dal momento che non puoi sapere che in molti casi, la soluzione predefinita è renderla il più semplice e comprensibile possibile.
Una cosa a cui pensare - un metodo a una riga è spesso ok perché puoi chiamarlo in modo molto più significativo per il tuo dominio. Se ho scritto una classe per contare le parole in una frase, il fatto di nominare un metodo chiamato parole che divide la mia frase in parole è ottimo per la leggibilità. Funziona particolarmente bene in ruby poiché i metodi e le variabili locali "si sentono" intercambiabili.
def words
scan(/\w+/).map { |w| w.downcase }
end
Leggi altre domande sui tag refactoring methods ruby