Qualsiasi risposta diretta sarà estrema. Chiaramente ci sono casi in cui la scadenza è così stretta che devi usare un codice brutto, e ci sono casi in cui il codice è così brutto che vale la pena perdere la scadenza per migliorarlo. Ciò di cui hai bisogno sono i metodi per giudicare in cosa ti trovi e forse i metodi per stabilire scadenze realistiche che consentano il tempo di scrivere codice migliore.
Non salvare la pulizia per dopo. A meno che tu non abbia abitualmente dei periodi con nient'altro da fare se non refactoring, non esiste un "dopo" in cui in qualche modo diventerà una priorità più alta per riordinare il codice di quanto non sia in questo momento. La routine è "rosso, verde, refattore", non "rosso, verde, fare qualcosa di completamente diverso per due settimane, refattore". Realisticamente non cambierai il codice fino alla prossima volta che lo rivedrai per qualche altro motivo, e probabilmente anche tu avrai una scadenza. Le tue reali opzioni sono risolverlo ora o lasciarlo.
Naturalmente un codice ben progettato è meglio di un codice mal progettato, supponendo che tu abbia intenzione di rileggerlo mai più. Se hai intenzione di non leggerlo mai più, non riordinare . Spedisci la prima cosa che supera i test. Ma questo è uno scenario piuttosto raro, per la maggior parte dei programmatori succede quasi mai. Ignorando quel caso, solo tu hai i dettagli del tuo caso reale per esprimere un giudizio su quanto costa riparare e quanto costa (in una futura manutenzione futura) non risolverlo.
Ci sono alcune cose che non sono più difficili da risolvere nel punto in cui il codice richiede manutenzione, rispetto a quelle che devono risolvere ora. Questi in realtà non ti aiutano molto a risolvere ora. I più ovvi sono banali da correggere (errori di spazi bianchi e simili) e quindi è difficile immaginare di avere il tempo di porre questa domanda ma non di risolverli ;-) Per quelli che non sono banali e sono di questo tipo, allora OK , hai del codice che non è l'ideale ma devi essere pragmatico. Funziona e sei in una scadenza. Usalo
Ci sono alcune cose che sono considerevolmente più facili da risolvere ora di quanto lo saranno in seguito quando (a) non sono così fresche nella mente di tutti; (b) sono state scritte altre cose che si basano su di esse o le imitano. Questi sono molto più preziosi da risolvere ora, quindi dai la priorità. Se non hai tempo nelle scadenze per risolverli, allora devi spingere il più forte possibile per scadenze più lunghe, perché stai accumulando debito nella tua base di codice 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 invialo al junior per cambiarlo . Potresti dare esempi di ciò che intendi e lasciare che il minore trovi tutti i casi nel codice a cui si applicano, ma non limitarti a terminare il loro codice. Se lo fai, non darai 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é. In definitiva, la ragione può essere "per rendere il nostro codice esteticamente coerente", ma se non sei disposto a scrivere le tue regole con qualche giustificazione, probabilmente non dovresti neanche applicarle. Lascia solo ogni programmatore libero di scegliere.
Infine, fai attenzione alla tendenza a modificare le cose indefinitamente. I ritorni diminuiscono e devi imparare attraverso l'esperienza dove sono ancora buoni. È assolutamente essenziale che tu formi un'idea realistica di ciò che è abbastanza buono, oppure non puoi avere quella negoziazione in cui ti assicuri che le tue scadenze ti diano il tempo di creare un codice "abbastanza buono". Trascorri il tuo tempo in cose che non sono abbastanza buone.