Refactorability is not an excuse for bad code

According to Wikipedia, "Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly preserving its meaning or behavior". Since the agile culture emphasizes refactoring of the code as necessary, it does set a new stage for code quality demands: How relevant is the initial quality of a code block? Can't refactorings be later used to "restore quality" as considered necessary? Is "high quality up front" an anti-agile beast on a level equal to "big design up front"?

"No!" screams the choir of agilistas. High quality has always been in the limelight in the agile methods community. The desire to use refactorability as an excuse for lowering the quality bar is cowboy coding, a mutilation of the agile ideals. In fact, quality is refactorability – only decent-quality code can be refactored, bad code must often be rewritten.

What is the true intended scope of refactoring, then? It is to avoid the need to build extensive hooks and abstractions for anticipated future needs. It is to enable flexibility that allows the design to adapt. All these ideals relate to changes in requirements or architecture, not to the quality preferences of an individual developer. If the main use of refactoring is reduced to making code conform to best practices or coding guidelines, many of the true benefits of refactoring are lost.

To summarize: Refactoring is not about using the rename pattern for fixing mindlessly named constants ("string s"). It is about turning a monolithic, bit-by-bit-grown customer object into a small class hierarchy to improve design. Be minimalistic, do what you need and only what you need – but do it with quality. If you see bad code, don't just accept "Feel free to refactor it" as an excuse – it's nothing but "I didn't care to do it properly" in disguise.

September 20, 2006 В· Jouni Heikniemi В· Comments Closed
Posted in: Misc. programming