Category: Learning Articles

Code refactoring is essential as software systems are used and improved upon. New requirements, use cases, and technologies will invariably force a development team to refactor applications and components in order to meet the goals of performance, maintainability, test-ability, separation of concerns, and so on.

But how do we as developers plan for this? Do we set aside dedicated time just for refactoring? Do we sneak it in along with our ongoing projects? Either approach can work. If it becomes apparent that upcoming large projects require existing code to be refactored, it’s best to plan to complete the refactoring prior to the project kickoff. Otherwise, if the desired refactoring is small, it can usually be accomplished in stream of ongoing projects.

When a development project is under strict time constraints, one of the first things I hear is, “I don’t have time to write any tests.” Or, “i’ll write some tests at the end, if I have time.” The presumption here is that automated tests are not critical or foundational or key to well designed code, clean code, good architecture, functional verification, etc. The presumption is that auto tests are “extra”, nice to have, and great if you have the spare time.

The basic flaw with this approach is that you have no way verifying the design OR the functionality of your code. You have no guardrails. Tests force you to design for SRP. Tests allow you to quickly confirm the functionality of the code against multiple test cases simultaneously during development. Tests functionally document your code to everyone else. Tests provide regression confirmation as new code is added, new functionality is added, bugs are fixed, requirements change, etc.