Refactoring

Key Insight

Software development is more akin to gardening than building construction, an organic process where code constantly evolves, requiring rethinking and reworking. Unlike a static building, software needs continuous adjustments: routines grow too large, designs need pruning, and elements need repositioning for better interplay. This ongoing process of rewriting, reworking, and re-architecting is generally called restructuring, with a specific, disciplined subset known as refactoring.

Refactoring is defined as a 'disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.' The key aspects are its disciplined nature, preventing a free-for-all, and the strict rule that external behavior must remain unchanged, meaning it's not a time for adding new features. It's a day-to-day, low-risk activity of small steps, like weeding, rather than a large-scale, infrequent overhaul. To guarantee no external behavior changes, robust, automated unit testing is essential to validate code behavior after each small modification.

Refactoring is triggered by new learning or better understanding, such as encountering code that no longer fits, noticing duplication (DRY principle violation), nonorthogonal design, outdated knowledge, shifting usage patterns, or performance needs. Critically, it should also be done 'when the tests pass,' providing an immediate opportunity to tidy up newly written code. Delaying refactoring due to time pressure is counterproductive; like a small 'growth' in the code, it's cheaper and safer to address issues early before they spread and become more complex and dangerous. Martin Fowler's tips emphasize not adding functionality while refactoring, having good tests, running them frequently, and taking short, deliberate steps, ideally supported by automatic refactoring tools in IDEs.