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.
For example, when we’re faced with a React application that is bloated, slow, and CPU-intensive, our immediate instinct isn’t to refactor the code to make it more performant. This seems a logical solution. We have a problem - bloated code - so identifying these areas and addressing the issues seems a sensible approach. However, this is rarely what happens in the ever-changing, evolving JavaScript ecosystem where there seems to be a multitude of new developments and technologies that allow us to continually patch our poorly written, sloppily structured code. These evolutions in the web development ecosystem are great, powerful tools and they allow us to continually move forward, adopt new approaches and operate in the margins of cutting edge technology. We are naturally drawn to them. They feel progressive, forward-looking, evolutionary. Something novel, something shiny, something new.
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.
As I thought about this point further, it became clearer to me that there are more examples of this. In recent years, the web development and JavaScript ecosystem reels off a history of taking good, well-tailored tools designed to enhance the technology stack and overusing those in ways to avoid refactoring.
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.
Top comments (0)