The Dreaded Refactor
The last thing you want to do is refactor. Why?
I came across the talk: “Develop, Debug, Learn” by Christian Heilmann this week, which got me thinking. In the talk, Christian Heilmann focuses in part on developer’s continually patching of increasing issues and the general failure of most developers to properly understand and address the problems with their code.
The dreaded refactor, on the other hand, is the antithesis of that. It involves dealing with legacy code - wading through the bog of ES5 syntax and perilous conditional statements. It feels too overwhelming. Furthermore, not only are we not progressing and learning new technologies. With the refactor, it almost feels like you're regressing. Treading trodden ground. Solving problems that have already been solved.
My immediate thought when writing this was Redux. The state management tool, which was almost a prerequisite to using React or so it seemed. In 2016, Dan Abramov, the creator of Redux, cautioned about using Redux unnecessarily in a blog post titled: “You Might Not Need Redux”. As applications have grown, Redux has become a handy device for dispensing with proper well-orchestrated local state in favour of stuffing, an ever-swelling global store full of localised data. As a result, the global state of many applications has grown too large, which has caused application load times to suffer. The logical solution here would be to revisit the global state and pare back its inefficiencies, remove the unnecessary data and ultimately refactor the code. The common solution here is adopt a practice like code splitting, so that we can patch up the problem: keep our oversized, global state, avoid a refactor while also improving the application load times.
As I read the ThoughtWorks technology review, it became clear across the web development spectrum there was a shared theme. While there were a few technological newcomers, there seemed several warnings of caution and overuse.
In the talk, Christian highlights various tools that have been developed to enhance the JS ecosystem, tools like Babel, Webpack, Sass. Tools that have their merit and serve a valid purpose, but have become ubiquitous with web development to the point that they often overused and abused. Moreover, they are support rafts for code that is badly in need of refactoring. Minification has a valid use case, and is absolutely necessary, but it has also provides additional latitude for inefficient code. Polyfills have usurped the need to understand nuances in browser behaviour. In the TechWorks Radar, browser polyfills are specifically called out, stating that all too often "web applications ship polyfills to browsers that don't need them". Code splitting allows the bloated bundles to be gobbled up in a more manageable way by the browser. All these techniques have their place, but all are used to some degree to patch inefficient code. They have become development solutions, rather than development enhancements.
While writing this, a question occurred to me: "When was the last time I properly refactored something?" I don't mean refactoring the code that you're currently working on. I mean you code an application, time passes, changes happen, which means that code now requires some attention. Do you refactor the code? Or do you reach for the nearest tool to help solve your issue? As developers, we too readily reach for the newest tool and make it fit, rather than rolling up our sleeves and embracing the dreaded refactor.