How do you prioritize and plan refactoring tasks in your code reviews?

In my experience the need for refactoring arises at the end of implementation cycles. Often we iterate through our development implementation either trying out new concepts or blocking out placeholder code for quick testing. This leads to a lot of dead code or unnecessary complexity. It can be somewhat easy to spot in a code review and we should always allocate time later in the process to refactor as a means to "clean up" technical debt.

When it comes to identifying the need for code refactoring, I've developed a practical rule of thumb. If the process of adding new features to existing code becomes increasingly challenging and complex, it often serves as a clear signal that refactoring is necessary. Another key indicator I consider is the difficulty in writing self-contained unit tests for the code. If this proves to be a formidable task, it often indicates the presence of code smells and structural issues requiring refactoring. Such code is often tightly coupled, lacks proper encapsulation, or has unclear responsibilities.

If you have automated testing in your project with high coverage, this greatly reduces the risk of breaking existing functionality or introducing new bugs while refactoring. While it takes time to write tests, the stability they offer often saves you time in support, investigation, development and deployment.

Effective scheduling and allocation of refactoring tasks are essential to maintain code quality and ensure the stability and performance of applications. - Schedule refactoring tasks as part of your regular sprint planning sessions. - Ensure that refactoring efforts are aligned with feature development to maintain progress and avoid delays. - Rotate responsibilities periodically to ensure that all team members are familiar with different parts of the codebase. - Prioritize refactoring during slower development periods or when addressing technical debt.

One time at work while reviewing our refactoring process, we've found it's valuable to assess the effectiveness and efficiency of our practices. One notable example occurred during a project for Traffic Management and Information Sharing system where we identified a significant portion of legacy code that hindered our development velocity and introduced risks. Through collaborative discussions and careful planning, we scheduled focused refactoring sessions, aligning with our sprint cycles to avoid disruptions. By dedicating specific time slots and involving relevant team members, we ensured accountability and transparency throughout the process.