Tidy First?

Capitolo 21. Prima, Dopo, Più tardi, Mai

Questo lavoro è stato tradotto utilizzando l'AI. Siamo lieti di ricevere il tuo feedback e i tuoi commenti: [e-mail]

Parliamo della tempistica del riordino rispetto a un cambiamento di comportamento nel sistema. Prima si riordina, poi si cambia il comportamento? Cambiare il comportamento e poi riordinare? O semplicemente prendere atto del disordine (nel senso che i futuri cambiamenti di comportamento saranno più difficili del necessario), e poi tornare più tardi a riordinare? Oppure non riordinare affatto?

Mai

Cominciamo con l'ultimo. Come sempre, deve esaminare i compromessi che comporta il non riordinare affatto. Quando dovremmo dire: "Sì, questo è un enorme pasticcio e scegliamo consapevolmente di non farci nulla"? Il motivo migliore è che non cambieremo mai più il comportamento del codice.

Ho posto questa condizione perché è raro che il codice non abbia mai bisogno di modificare il suo comportamento. Tuttavia, capita. Per i sistemi veramente statici vale il detto "Se non è rotto, non aggiustarlo".

Più tardi

Alcuni pensano che il riordino tardivo sia pura fantasia, un unicorno, un politico onesto. Lo status mitologico del riordino tardivo viene usato come giustificazione per riordinare troppo ora, sia prima che dopo. Io sono qui per dirti che puoi davvero riordinare dopo. Il prerequisito, però, potrebbe non piacerti.

C'è abbastanza tempo per fare il tuo lavoro? Non ti sto chiedendo se haimolto tempo a disposizione, ...