I wrote earlier about the need to refactor your codebase continuously – making small improvements on a regular basis. In this post, I want to elaborate on why continuous refactoring is such a wise investment. With continuous refactoring, you get several benefits:
- Helps you recognize and correct incorrect domain understanding. When you move a parameter from one class to another or make an atomic parameter a collection – you are refactoring to align your code with your domain. These changes will help you address evolving requirements faster and in a more natural manner.
- Reduces the probability for massive re-design of your code: when you continuously refactor, you are making improvements. You may introduce a constant / access data from a properties file to remove hard-coded values or apply a new design pattern that helps with a tricky requirement. These changes align your code and design better – For instance, your initial implementation might have sent data to another object directly. You realize in a subsequent iteration that more than one process needs this information. You refactor your code to introduce patterns or simplications – this process is iterative.
- Continuous refactoring makes the domain model more explicit and easy to understand. It is natural to accumulate business knowledge as you proceed through development and without refactoring this new knowledge will get lost.
- Continuous refactoring also provides the opportunity to review your code – for bugs, for deviations, for needless complexity, missed opportunities for reuse etc. You can make refactoring a necessary follow-up action as part of design reviews and code reviews.
Having said all this – the key concept to recognize is the need for continuity and discipline. An incremental improvement may not seem like a big gain and it isn’t always. However, small changes do add up to significant gains over multiple iterations. In a follow-up post I will provide concrete examples of using refactoring to improve the quality of your codebase.