When do you perform a major refactor?

Summary

In this video, Frederick discusses the decision-making process behind major codebase refactors. He highlights when poor system quality, difficulties in adding features without causing regressions, and a lack of confidence in the code prompt a need for a refactor. Frederick advises against full rewrites, recommending a strategy of breaking down and decoupling problematic parts incrementally. By focusing on ‘picking leaves’ and addressing the simplest dependencies first, teams can improve code quality over time without overwhelming rewrites. The key is consistent, small improvements, though getting teams to commit to this process can be challenging.

Takeaways

• 😀 Major refactoring should be done when there are consistent quality issues in the system.
• 😀 If adding features or writing unit tests is challenging due to the existing codebase, it's a sign that a refactor may be necessary.
• 😀 Just because a feature works doesn't mean it's well-structured for future enhancements; it may need to be refactored before adding new features.
• 😀 Avoid 'shim programming' where additional features are added without addressing the core issues of the codebase, leading to increased complexity.
• 😀 A major refactor doesn't require a complete rewrite, but rather a strategy to simplify and decouple parts of the system.
• 😀 Breaking down large, monolithic components into smaller, more manageable pieces is key to improving code maintainability and stability.
• 😀 The process of refactoring should follow a 'pick leaves' approach, where you focus on the least dependent components first to gradually untangle the system.
• 😀 Refactoring is about continuous improvement. It’s important to get everyone on the team to stick to a strategy and be consistent in applying it over time.
• 😀 The biggest challenge with refactoring is not developing a strategy but ensuring the team follows through consistently over time.
• 😀 Confidence in the codebase should be maintained. If you're afraid of introducing regressions or releasing new features, it’s an indicator of deeper structural issues.
• 😀 Teams should focus on gradual improvement through topological changes, starting with the most independent components and gradually untangling dependencies.

Q & A

When is the right time to decide on a major refactor of an existing codebase?

A major refactor is necessary when you consistently encounter issues with quality, such as difficulties in writing basic unit tests, adding new features without causing regressions, or struggling to extend existing functionality without rethinking the entire implementation.

Why is it important not to just keep adding features to a system without refactoring?

Continuously adding features without addressing the underlying structure can lead to what’s called 'shim programming,' where the system becomes more complex and fragile over time. This results in a system that is difficult to maintain and extend, similar to constantly adding parts to a broken car.

What is the concept of 'boy scouting' in refactoring?

Boy scouting refers to the practice of making small, incremental improvements to the system, like tidying up parts of the code, even if they are not directly part of your current task. This helps maintain or improve the system's overall structure over time.

What is the role of a dependency graph in refactoring?

A dependency graph helps visualize the relationships between different components in the system. By identifying which components are least dependent on others, you can determine where to start refactoring, often beginning with components that are easier to decouple.

How does Frederick approach the challenge of large, complex refactorings?

Frederick suggests tackling large refactorings step by step. Instead of attempting a complete rewrite, he recommends breaking down the system into smaller, more manageable pieces. The process involves identifying and isolating the components that are easiest to refactor and gradually decoupling them.

What is meant by 'picking leaves' in the context of refactoring?

'Picking leaves' is a metaphor for starting the refactor process with the least dependent parts of the system. By addressing these 'leaves' first, you can begin decoupling and simplifying the system without disrupting the more critical components.

What challenges do teams face when trying to consistently apply refactoring strategies?

Teams often struggle with consistency due to a lack of time, scope creep, or resistance to change. Some team members may prefer to tackle problems with big rewrites instead of incremental improvements, which can lead to frustration and inefficiency.

Why is coupling a major issue in codebases that need refactoring?

Coupling refers to the interdependence between different components. When components are tightly coupled, making changes to one part of the system can have unintended consequences elsewhere. This makes the system difficult to modify and prone to regressions, which is why decoupling is often a central goal in refactoring.

How can a team handle refactoring while still making progress on other features?

One effective strategy is to break the refactor into smaller, manageable tasks or 'stories.' By continuously working on small parts of the system and improving them, the team can avoid the risks of big rewrites while still making gradual progress toward a cleaner, more maintainable codebase.

What does Frederick mean by 'it's a bit like going to the gym' in relation to refactoring?

Frederick compares refactoring to maintaining a gym routine because, like physical fitness, refactoring requires consistent effort over time. It’s easy to overlook or neglect, but when done regularly, it yields significant benefits to the system's health and maintainability.