When starting new developments on an existing application, we often set a strategy for ourselves to improve the quality as compared to what was done before.
For this, we:
- Carry out targeted corrective actions on the existing code, actions that are quick to implement, whose benefits are concrete, and that will not increase the non-regression testing effort.
- Start with more ambitious quality objectives for the new code so that we do not reproduce existing problems and so that we do better from the start in order to avoid problems rather than correct problems.
It is difficult, however, to balance these two approaches, since traditional code quality tools analyze the entire project without differentiating between existing code and new code. As a result, when applying the desired rules, the tools generate a huge volume of alerts for the existing code. They drown the team in information, making it difficult to use. Consequently, the quality objective loses steam and is eventually limited to a few rules to be applied on the new and old development.
The Cockpit allows a different approach by keeping only the existing problems we want to correct in its radar to be sure that progress is made, while holding new development to stricter requirements.
This approach is quick and easy to implement in just 4 steps:
- Perform a quality diagnostic on the application. This diagnostic provides a clear view of the situation by using an automatic analysis of the code and returning qualitative and quantitative information on the problems it finds.
- Target the improvements to be made. Based on the diagnostic, you must decide which problems to solve and then prioritize them to follow the project constraints. The results of analyses performed with the Cockpit show that there are mainly critical problems corresponding to bugs that have been corrected (concurrent access problems, incorrect instructions, etc.) Other problems may be structural (non-maintainable code), excessive copy/paste code left too long and needing to be correct, or even problems with a major regression risk.
- Clear the quality radar of problems that will not be corrected right now. With the Cockpit, quality rules can be disabled only for specific portions of code (method(s), class(es), module(s), etc.) so as to skip existing code. Reset mode also makes detected problems disappear in a given version by only considering newly detected problems. For example, it no longer detects overly complex methods that cannot be changed, but it detects all new overly complex methods.
- Share this view with the entire project team and monitor the implementation of the process. Make it standard usage to visit the Cockpit and dashboards to control quality throughout the project.
During the next iteration, we configure Cockpit to include other improvement actions, if necessary.
This approach was designed to meet the needs of our customers who need to control overall project quality by distinguishing new development and improvements to existing code. For example, the approach is used for maintenance projects that are used internally or via a TPAM.
