Techniques to do continuous refactoing
I've come to believe that continuous refactoring is a good way to maintain the health of a system that is in continuous development. That is, a system for which new features are always in the pipeline. By 'continuous refactoring' I mean to make small updates to code surrounding the new feature being added or modified. While working on the feature, the particulars of the code will be in the programmers mind, so this would be an appropriate time to make related improvements. In this refactoring approach, there are always improvements made to the system, separate from the new features being added. It also affects the mentality of the programmers -- to think of continuous improvement of the system as something natural and desirable. There would still be tasks solely devoted to refactoring (as opposed to doing them alongside features). Those are reserved for bigger changes. In a rough estimation, I would consider it appropriate for a programmer to do a medium size refactoring about once every 3-6 months. For large refactoring, those would be rare; those need to be planned carefully, and only done when specific needs have been identified. As to what constitute a 'medium' vs 'large' refactoring, that is dependent on the particulars of the system. However, there is an issue with continuous refactoring which I want to overcome, and which is the subject of this post. When working on a feature, the ideal set of changes include only the updates needed to implement the feature. This way, other programmers that review the code only need to concern themselves with the required changes. But, this is exactly opposite of the idea of continuous refactoring. So, on one hand, making changes only related to the task at hand is good for reviewing the code; while on the other hand, the associated refactoring is good for the long term health of the system. What are some ideas to overcome that challenge: to be able to make small refactors while working on features, whilst being able to separate the feature changes from the refactor changes such that they are easy to review in isolation?
I've come to believe that continuous refactoring is a good way to maintain the health of a system that is in continuous development. That is, a system for which new features are always in the pipeline.
By 'continuous refactoring' I mean to make small updates to code surrounding the new feature being added or modified. While working on the feature, the particulars of the code will be in the programmers mind, so this would be an appropriate time to make related improvements.
In this refactoring approach, there are always improvements made to the system, separate from the new features being added. It also affects the mentality of the programmers -- to think of continuous improvement of the system as something natural and desirable.
There would still be tasks solely devoted to refactoring (as opposed to doing them alongside features). Those are reserved for bigger changes. In a rough estimation, I would consider it appropriate for a programmer to do a medium size refactoring about once every 3-6 months. For large refactoring, those would be rare; those need to be planned carefully, and only done when specific needs have been identified. As to what constitute a 'medium' vs 'large' refactoring, that is dependent on the particulars of the system.
However, there is an issue with continuous refactoring which I want to overcome, and which is the subject of this post.
When working on a feature, the ideal set of changes include only the updates needed to implement the feature. This way, other programmers that review the code only need to concern themselves with the required changes. But, this is exactly opposite of the idea of continuous refactoring. So, on one hand, making changes only related to the task at hand is good for reviewing the code; while on the other hand, the associated refactoring is good for the long term health of the system.
What are some ideas to overcome that challenge: to be able to make small refactors while working on features, whilst being able to separate the feature changes from the refactor changes such that they are easy to review in isolation?
