Code should be refactored, here is why

When code is refactored it gets better. What does “better” mean when it comes to code? Well it means better for documenting (or more consistent with documentation). It means faster, more performant. It means more scalable.

We can theorize that most of the business potential of code (generally speaking) is lost simply because most code is the digital equivalent of a green banana. Have you ever eaten a green banana? It’s starchy, it’s crunchy, it’s bitter, and nobody in their right mind would eat one in it’s entirety. Yet if you just let it ripen, a few days later it’s one of the tastiest fruits the world has to offer. Suitable to eat raw or combine into any number of delectable dishes. Why then would we ever settle for code that is more ripe than ready?

Refactored code works out the deficiencies. Anybody who thinks the best version of any function or class is written on the first try is naive at best. It’s an ignorant idea that developers should “just write code properly the first time”. Unfortunately some people have that idea and have the budget control over projects. In reality, pushing forward first draft code to a real live project is no different than publishing the first draft of a book. This book has over 100 grammatical errors, the flow between chapters is illogical… so let’s print a million copies. Not so fast intelligent project manager! Let’s consider at least making 1 round of refactoring.

The returns on refactoring do eventually reach their peak. And the question of “how many rounds of refactoring do we need” is an open one. To some extent it does relate to both the quality of the original developers approach, and also the approach of the developer doing the refactoring. What’s needed here is a reasonable way of measuring code quality. That’s obviously not easy. We can easily spot “junk code”, and bulky functions and poorly thought out solutions. But can we spot potential for improvement in a codebase that already “looks good”? Can we differentiate between refactoring that has a tangible benefit versus “improvement for the sake of improvement”?

Similar Posts