Quando il tuo istinto ti dice che probabilmente dovresti eseguire un refactoring, è probabile che sia il tuo istinto a dirti con un po 'di ritardo che hai messo qualcosa di importante troppo a lungo.
I understand "code-smells", red-green-refactor and other thoughts, but often I feel that the best time to refactor is not the first time you write the code, but the second or third time you are using the code and realize that it is actually a problem and is in actual use.
Ci sono effettivamente due livelli per il refactoring. Il primo è l'ovvio problema che appare quando si esegue il primo codice. Queste sono le piccole ottimizzazioni che ti costano molto poco da fare in anticipo. Cose come mantenere piccoli metodi e classi e aderire a DRY e SRP. Poi hai la fase aggiuntiva di gestire i principali difetti del tuo progetto, che potrebbero non essere immediatamente evidenti fino a quando il tuo codice non avrà un paio di miglia sotto di esso. Si tratta di questo secondo livello di cui si sta parlando e, tuttavia, per garantire che il successivo refactoring non sia troppo costoso, è necessario aver già scritto il codice in modo tale che lo sforzo che si prevede in seguito sia reso più facile e meno costoso, il che significa fare un refactoring anticipato.
Come Jeff ha detto nella sua risposta, "il tempo è denaro" , in particolare nelle aziende in cui il carico di lavoro è elevato e i rischi ancora più elevati. Il tempo trascorso in anticipo assicurandosi che il codice sia nel suo stato migliore possibile è il tempo risparmiato in seguito, quando prendere in giro ciò che avrebbe dovuto essere un semplice refactoring si rivela essere un'operazione importante.
Quando scrivi software, ogni momento dedicato a migliorare il tuo codice in anticipo viene salvato più tardi, quando ne avrai davvero bisogno. Quanto prima ti rifatti, più chiari saranno i tuoi successivi cambiamenti. È come fare un acconto in dollari di oggi contro il debito tecnico futuro che sarà in dollari gonfiati domani.
In ogni caso, il refactoring non dovrebbe essere un compito che rimanderai a qualche futuro misterioso quando il software è già completo e stabile, poiché aumenta i tuoi rischi più tardi quando la posta in gioco è molto più alta e il prodotto molto più difficile da modificare. Il refactoring dovrebbe essere una parte delle tue attività quotidiane, e questa è l'essenza della filosofia Red-Green-Refactor che hai menzionato.