Il refactoring è come ritirare la tua stanza.
Se mantieni le cose in ordine, hai un overhead lineare, proporzionale alla quantità di lavoro produttivo che stai facendo sul codice, O (n) in termini algoritmologi. Supponendo che spendi il 10% del tuo tempo per il refactoring (o per tenere in ordine la tua stanza), quel 10% è un dato, e rimarrà costante nel tempo.
Se, tuttavia, lanci i vestiti sporchi in un angolo e continui a farlo, la quantità di tempo che trascorri a raccogliere la tua stanza aumenta man mano che il casino diventa più complesso. Supponendo che ogni singolo pezzo di biancheria sporca contribuisca esponenzialmente al tempo necessario per la pulizia, ora ci si trova in una situazione O (e n ).
Chiunque abbia mai scavato nel concetto di complessità algoritmica osserverà che c'è un punto di pareggio da qualche parte, cioè c'è una quantità ottimale di biancheria sporca da accumulare; quanto dipende dai fattori costanti che vengono scartati nella notazione big-O. Un altro fattore è il valore del tuo lavoro nel tempo: se il tuo lavoro vale molto ora, ma a buon mercato la prossima settimana (cioè, c'è una scadenza questo venerdì per questo progetto e altri tre, ma dopo, sarai per lo più inattivo ), l'equazione potrebbe risultare in favore del non refactoring.
E poi c'è la massa critica della complessità. Ad un certo punto, il caos ('pasticcio critico', se vuoi) diventa così grave che sembra più facile bruciare l'intera stanza e comprare nuovi vestiti. In realtà di solito non lo è, ma sembra così, e gli effetti psicologici renderanno dieci volte più difficile affrontare la cosa.
E ovviamente, se entri in un progetto che è già un enorme pasticcio ridondante, hai una scelta limitata.
TL; DR: in caso di dubbio, refactoring. Dovresti avere delle prove davvero buone prima di decidere di non farlo.