Refactorings and How to Plan Them? (重构以及如何计划重构?)
With the agile software development becomes the main stream of software development mindset, refactoring is one of the practices that are employed by more and more software developers and teams, one of the reason is the big upfront design is not recommended in any agile software development methods, instead, it is believed that the good software structure could be emerged from the bad code base that has code smells through continuously refactoring, by making small changes in the code every time with the help of unit test and design patterns.
Software with good code quality is a value asset of any organizations, and the code with bad smells is another side of it which has equal or even more values, because it indicates the development opportunities to the developers and the team, provides a lot of chances for the team to learn, to think about how to improve, and to practice refactoring technologies which further grow the overall team capability.
No big upfront design is good in the concept, but it does not mean there’s no design at all in the agile development. Design is required no matter development methods is being chosen, it is just a matter of to which degree and how much effort will be spent on the design. It is just two sides of a coin, if you don’t do design, then you’ll have to experience the pain and spend efforts to restructure the design through refactoring, and if you do spend time to do some design, most probably, refactoring is only required when it really required.
The question here is, during the software planning or Sprint planning in Scrum, how do we know what kind of refactoring and how much effort should be planned?
Refactoring categories
To avoid confusion, before moving on with the discussion, it would be worthwhile to define the types of refactoring. Looking from the scale perspective software refactoring could be classified into:
1. Large refactoring
This type of refactoring typically involves significant change in the software structure/architecture which requires a few of weeks or even months to complete. From technical perspective, it is an indicator of poor software design. And from process perspective, it indicates nobody is care about the software quality, and the debts has been accumulated for quite a long time without being paid off.
2. Medium refactoring
The medium refactoring often requires significant changes to one or two software modules which may require a few days of efforts. It is an indicator of poor software module design. It also indicates technical debts has been accumulated in some areas of the software and may cause significant issues if not being paid off.
3. Small refactoring
This is the refactoring that most of software developers point to when the refactoring is referred, but what makes people confusing is they’re actually doing either medium or large refactoring when the small refactoring is referred. Small refactoring often requires local code changes and could be performed within one hour or even shorter with the help of refactoring tools.
Four blocks
Going back to the question, what determines how much should be planned for the refactoring? It depends on two factors: design maturity and implementation maturity.
1. Design maturity
The overall capability of the software design skills of the team and the software design quality of the software in discussion determines the design maturity. The maturity is high when either or both there many people in the team good at software design and the software being developed is well designed.
2. Implementation technology maturity
The knowledge and experience of the specific implementation technologies, such as a programming language, software frameworks, operation systems etc. determines the implementation maturity. The maturity is high when there’re lots of implementation skills and experiences within the team.
There’re four blocks if divided the spaces from the perspective of design maturity and implementation maturity. And every block indicates why type of refactoring that should be planned and how much efforts required:
1. Low design maturity and low implementation maturity
It would be very unfortunate if any software program falls into this block, because it indicates the team does not know how to design and implementation the software which would be a big trouble for the program. Team must plan a big amount of time to do the large refactoring in order to maintain the code quality. As another choice, team can redevelop everything after the first version was implemented which may be a big waste.
2. Low design maturity and high implementation maturity
Team knows everything on the implementation technologies; however, the design is not in place or nobody is good at design the software architecture. In this case, team would need to spend some effort to do the medium refactoring in every Sprint, e.g. one week for a two weeks’ Sprint.
3. High design maturity and low implementation maturity
In this case, the software should be well designed, but there might be some issues in the implementation. Team needs to do the medium refactoring in every Sprint, but the actual efforts would be in between of a small refactoring and a medium refactoring, e.g. each refactoring could be done within one or two days.
4. High design maturity and high implementation maturity
This is the ideal situation where the software is well designed and team knows everything of the software implementation, most of time, the code is in good quality and matches the software design. Just small efforts would be required in the Sprint, and it could be either planned or not planned depend on the way team works, e.g. it would not require a plan if everybody has a built-in mindset and skilled in do small refactoring within 5 minutes every time.
Conclusion
There're a few of conclusions that could be made from the discussion above:
- The refactoring should be planned based on the assessment of the design maturity and implementation maturity, which determines what kind of refactoring should be planned.
- The four-block diagram also provides two approaches for a team to improve:
a. if the team is in the first situation , it should go either from 1 to 2 by improving software implementation skills first and then developed futher into 4 or from 1 to 3 by improving software design skills first and then 4.
b. It would be very difficult if a team in situation 1 that want to improve both software design and implementation maturity skills at the same time, because Rome could not be built in one day.
But I will end the dicussion with another open question, that is if a team is in situation 4, which has a high maturity in both design and implementation, is it really good if it stays in this area?