The tools I listed two issues ago allow developers to monitor, measure, track and identify areas of improvement. Without the tools, developers are left to their own devices and teams must spot code reviews on their own, which typically are difficult to track.
More importantly, the tools not only enable the developer but also the team lead. No longer is the team lead left to manually inspect code or call code review meetings. A team lead may leverage the tools to measure and monitor the entire codebase, thereby controlling and ensuring system quality throughout the development lifecycle.
Stepping stones for change
The saying goes that Rome was not built in a day and the same holds true for implementing quality control processes for your J2EE- or Java-based projects.
Attempts to introduce a process from the ground up can possibly result in failure. Many people are adverse to change and developers are no exception.
New facets of a process should be introduced slowly because favourable reception can be better ensured through the gradual introduction of “gates.”
Also known as a checkpoint or a review, a gate is a recognized point in time during development that involves a deliverable in the form of an artifact by the owner and a task in the form of a review by a set of the artifact’s stakeholders.
Gates must be passed to promote code from development to quality assurance or to production. A project’s history and its state — whether it has yet to start, or is ongoing — dictates what gates to introduce first. Before introducing the gates to the development team, take time to identify the order in which your project needs to introduce the gates. The needs of every project differ based on its members’ strengths and weaknesses. Identify the quality increases that the project can best benefit from and then adopt the appropriate gates to realize them.
After you have identified the order in which the gates will be introduced, pull your team members together and give them a brief overview of the tools/ plug-ins and their capabilities. Give them direct links to accessing the plug-ins or make the plug-ins available on your local area network. Make sure the developers install each plug-in.
This strategy won’t guarantee developers will use them, but it will improve the odds. Once the developers have installed the tools, discuss in detail each gate you plan to introduce.
Checkstyle review gate
Discuss Checkstyle’s configuration settings and why they are being used. Let your developers know that all errors must be fixed and discuss whether warnings should be fixed. Be sure developers understand that they must use Checkstyle and that their use of it will be checked at the end of every iteration.
JUnit review gate
A JUnit report should be generated at the end of each construction iteration, as it is used to continually measure the system’s reliability. Developers should run any unit tests of code they have changed or affected prior to the code’s check-in to version control. Be sure to identify a location for historical reports so everyone can review old reports and compare them with new reports to understand how the project is progressing.
Metrics review gate
Discuss the capabilities of the metrics review along with any customization that has been done. Make sure developers configure their metrics plug-in in the same way so they have the same view. Ask them to have the plug-in turned on at all times while coding so they can quickly check the metrics view for problems when changing code. Again, remind the team that the code metrics will be monitored at the end of every construction iteration.
Jupiter team review gate
The Jupiter review requires the introduction of some form of review process. A naming schema for review IDs will need to be established, as well as responsibilities for entering and resolving issues. Once the review process has been defined, discuss the process with the team. As a general rule of thumb, have a continually open code review ID that any issue can be attached to, and separate review IDs for specific reviews.
GroboCodeCoverage
Identify and explain coverage expectations to the team. List the types of reports to generate via GroboCodeCoverage, when the reports will be generated, and where they will be stored. At a minimum, the source coverage report should be generated as this provides the most information in a centralized report.
Measure and inform
By introducing the gates slowly, the chances of the new plug-ins being utilized are improved, which improves the quality of both the codebase.
Jarrett is an enterprise architect with The Cobalt Group, a Seattle software development firm.
Quick Link:056662
