Ogni risposta diretta sarà estrema. Chiaramente ci sono casi in cui la scadenza è talmente stretta da dover usare un brutto codice, e ci sono casi in cui il codice è così brutto che vale la pena perdere la scadenza per migliorarlo. Quello di cui hai bisogno sono i metodi per giudicare in che modo ti trovi, e forse i metodi per impostare scadenze realistiche che ti permettono di scrivere un codice migliore.
Non salvare la pulizia per dopo. A meno che non si abbia abitualmente periodi con nulla da fare se non refactoring, non c'è "più tardi" in cui in qualche modo diventerà la priorità più alta per riordinare il codice di quanto lo sia in questo momento. La routine è "rosso, verde, refactoring", non "rosso, verde, fare qualcosa di completamente diverso per due settimane, refactoring". Realisticamente non cambierai il codice fino alla prossima volta che lo stai rivisitando per qualche altra ragione, e probabilmente anche tu avrai una scadenza. Le tue vere opzioni sono di ripararlo ora o lasciarlo.
Ovviamente il codice well-styled è meglio del codice in stile cattivo, supponendo che tu abbia intenzione di leggerlo di nuovo. Se hai intenzione di non leggerlo più, allora non riordinarlo . Spedisci la prima cosa che supera i test. Ma questo è uno scenario piuttosto raro, per la maggior parte dei programmatori accade approssimativamente mai. Ignorando tale caso, solo tu hai i dettagli del tuo caso reale per esprimere un giudizio su quanto costa fissare rispetto a quanto costa (in una maggiore manutenzione futura) a non risolverlo.
Ci sono alcune cose che non sono più difficili da risolvere nel punto in cui il codice richiede manutenzione, piuttosto che risolverle ora. Questi in realtà non ti danno molto da sistemare ora. Le più ovvie sono banali da correggere (errori di spazi bianchi e simili) e quindi è difficile immaginare che tu abbia il tempo di fare questa domanda ma non di risolverle ;-) Per quelle che non sono banali e sono di questo tipo allora OK , hai un codice che non è l'ideale ma devi essere pragmatico. Funziona e sei in scadenza. Usalo.
Ci sono alcune cose che sono considerevolmente più facili da sistemare ora di quanto lo saranno in seguito quando (a) non sono così freschi nella mente di tutti; (b) sono state scritte altre cose che si basano su di loro o le imitano. Questi sono molto più preziosi da sistemare ora, quindi assegnali le priorità. Se non hai tempo nelle tue scadenze per sistemarle, devi spingere il più possibile per scadenze più lunghe, perché stai accumulando debiti nel tuo codice base che probabilmente dovrai pagare la prossima volta che visiti il codice.
Il metodo preferito per correggere il codice è attraverso un processo di revisione. Commenta i problemi che hai con esso, e rimandalo al junior per cambiare . Potresti fornire esempi di ciò che intendi e lasciare il junior per trovare tutti i casi nel codice a cui si applicano, ma non solo finire il loro codice per loro. Se lo fai, non dai loro alcun mezzo per migliorare.
Dovresti scrivere i problemi più comuni in una guida di stile che dice "non farlo, fallo invece" e spiega perché. Alla fine si può permettere che la ragione sia, "per rendere il nostro codice esteticamente coerente", ma se non sei pronto a scrivere le tue regole con qualche giustificazione allora probabilmente non dovrebbero farle rispettare o. Lascia ogni programmatore libero di scegliere.
Infine, fai attenzione alla tendenza a modificare le cose indefinitamente. I rendimenti diminuiscono, e devi imparare attraverso l'esperienza in cui sono ancora buoni. È assolutamente essenziale formarsi un'idea realistica di ciò che è abbastanza buono, altrimenti non si può avere quella negoziazione in cui ci si assicura che le scadenze ti consentano di creare un codice "abbastanza buono". Passa il tuo tempo a cose che non sono abbastanza buone.