Step 4: Static Analysis and Code Review
To complete the loop, any new code needs to be analyzed by the same static-analysis process that was established in Step 1. Ideally, programmers perform static analysis on their desktops so that they can check and correct code before committing it to source control. Even if this is not possible, the new codeonce it is committed to source controlis still subject to static analysis when the batch process checks all code available in the code base.
Once the new code passes all the checks, including a clean bill of health from static analysis and regression testing with sufficient coverage, it should be finalized by a team code review. It does not really matter how the code review is conductedit can be integrated into the code-authoring process (as in pair programming), distributed to programmers with automatic notification based on source-control commits, or performed in the old-fashioned manner by gathering people into a room with code printouts. The key is to have the code reviewed by humans.
This four-step process illustrates how C++ development teams can approach the common C++ development tasks of managing and modifying unfamiliar legacy code in a way that promotes a methodical approach and yields high-quality results. Although each of the techniques I introduce is a good practice on its own, combining them in an automated process framework helps teams effectively address their productivity and code-quality goals, as well as confidently manage development risks. Further gains can be realized by monitoring and continually improving the process.