Keep Your Code Base Clean with Regular Refactoring
Refactoring is a discipline in the development of a software product involving restructuring of code, altering its internal structure without modifying its external or observable behavior.
As the development team crafts the software from the beginning of the sprint with the goal of a shippable increment, the code is not fine-tuned for perfection or efficiency, including neglecting nonfunctional requirements. As the sprint progresses, more code gets added to the existing code base, making it fragile.
There are a number of possible reasons behind the bad code:
- An aggressive release schedule making developers take short cuts
- Laziness and incompetence of developers
- High technical debt due to poor technical practices and standards
- Inadequate testing
- Development team silos, both in knowledge and in the code base
- Delay in fixing dirty code leading to code brittleness
The Boy Scouts have a rule: “Leave the campground cleaner than you found it.” You should apply the same principle to your code. Merciless refactoring prevents code rot by keeping the code base clean and easy to maintain.
The test-driven development methodology pictured below—popularly called the red, green, refactor cycle—focuses on regular refactoring as the design evolves during the course of the development.
The development team should educate the product owner on how refactoring can make life easier. The team can spend a relatively small amount of time—maybe 10 percent—on refactoring bad code from sprint to sprint, leading to better code stability. Refactoring activities can be added to the product backlog as user stories based on mutual agreements, so they can be picked up for sprint planning successively.
There may be prioritization challenges between new features and refactoring, and the team must understand that a system that is robust can extend more features—not an unstable one.
Pair programming and code review techniques promoted by Extreme Programming can help developers write cleaner code the first time. These practices point out to programmers where they can remove too many nested loops, get rid of complicated conditional statements, and improve modularity of the code by reducing the number of lines. Automated tests provide feedback quickly on the refactored code, whether or not we’ve changed the behavior of the system. Developers having a clear understanding of the definition of done can help in removing bad code as well.
Refactoring should not be a Sisyphean effort; it just needs a lot of patience and discipline from the team. Just like how the code is built line by line, module by module, refactoring should also be focused on unplugging bad lines of code by removing bad variables, bad classes, or bad methods one at a time.
If the team is able to implement a rigorous process within the sprint to eliminate bad code, or to negotiate with the product owner to have user stories added to the backlog for refactoring, it can help to pay down the principle of technical debt.