Piccoli refactoring su un codebase scadente?

La mia opinione è che il refactoring sia incluso nella distribuzione di nuove funzionalità. Presumo che lasciare un buon codice alle mie spalle sia un'aspettativa per il mio lavoro e per l'anzianità.

Pertanto, in un caso come il tuo, rifatterò tutte le parti che sono interessate da qualsiasi modifica, e includo i tempi di refactoring nelle stime che fornisco.

Se la tua gestione non comprende il concetto di debito tecnico e i costi per ripagarlo o non supporta una ragionevole quantità di refactoring, potresti essere molto limitato nella tua posizione attuale.

Non ti dovrebbe mai essere chiesto di consegnare il codice crap, entro limiti ragionevoli. Se lo sei, la risposta standard è "Perché non assumi un programmatore junior per scriverlo? Costano sicuramente meno di me."

Le righe di 40k di codice sono piuttosto piccole, ma se è un codice critico, è comunque un investimento significativo di tempo.

Tutti vorremmo lavorare su un codice sexy e meraviglioso, ma il business case è sempre basato sul ritorno. Ti costa così tanto tempo all'anno, che risparmierai tempo mettendo in grandi correzioni? O funziona abbastanza bene da non poter giustificare il tempo?

Nella mia esperienza, i programmatori vogliono tutti sostituire il codice dei loro predecessori. È una strong tentazione (perché sono tutti idioti incompetenti / pazzi / schifosi) ma se funziona, lascia stare. Cerca di concentrarti sul codice in modo che la persona successiva a cui tenere il tuo lavoro non senta la necessità di riscriverlo it .

Penso che molte piccole correzioni possano portarti da qualche parte. Non penso che sia necessario mettere da parte una grossa fetta di tempo per ridimensionare il codice malamente ingarbugliato in buona qualità.

Guarda dove sei e dove hai iniziato. All'inizio era brutto, e adesso è brutto, ma è meglio? La mia ipotesi è che sia così. Potrebbe non migliorare quanto velocemente, ma non lo è mai, ma se migliora e continua a migliorare, sei già sulla strada giusta.