The backbone of a successful app or software is its impeccable code. This has to be kept pristine, else the app will fail. For the code to be flawless, it has to be reviewed constantly. This can be achieved manually or through the use of a dedicated tool. Some pretty decent tools in this area are FindBugs, PMD, CheckStyle and SonarQube.
The reason why legacy software survived the dynamics of maintenance for years was due to the discipline and diligence followed by the engineers. This is more of a culture, which was embedded in the system and eventually helped in maintaining the rhythm of the IT growth we have seen so far in India.
In the early stages of this revolution, software companies put together a lot of processes and tried their best to institutionalise these across the organisation. They took industry standards as benchmarks, and worked hard in getting the required certifications and assessments to label themselves as professional practitioners in software development and maintenance. Certifications like ISO, CMM, CMMi, etc, helped organisations in clinching some of those multi-million dollar outsourcing deals from MNCs by instilling the necessary trust and confidence.
Just taking this a few levels down, the software development life cycle included a lot of checks and controls to ensure that the quality was taken care of. This was made possible through the identification of bugs, both during compilation and at the run time. The analysis of source code, also called static analysis, helps in identifying the bugs prior to getting it to runtime through the testing team. There are some industry metrics that have evolved over a period of time, and these need to be evaluated on a continuous basis to stay relevant. Of course, they may depend on so many other parameters and may depend on the project at hand too.
Just as we have proof-reading for all the writing exercises, there is a need to have something similar for the code we develop, and it has to be an independent exercise performed by somebody other than the actual developer. Overall, the intention is to catch all the blind spots that the developer might have overlooked. There may be many reasons for these issues to creep in, like the lack of enough experience, or the ‘silo approach’ of focusing on the immediate problem and ignoring the holistic perspective, etc.
Though the experience may help in minimising some of these errors, it can be a challenge to reduce it by 100 per cent; so this exercise is important irrespective of the developer’s experience.
Some of the aspects that can be handled as part of the code reviews include:
- Coding standards violation
- Inefficient use of programming constructs
- Possible code complexity
- Documentation
Though there are a few good tools to handle code reviews, these were purely manual when software development started out. Today, companies carry out a blend of both manual and tool-driven reviews to ensure broader coverage.
Typically, every experienced software development company has its own process established at the organisational level, which is followed by all the project teams. There is a separate department called SQA or Software Quality Assurance (the names may differ across different organisations), which oversees and facilitates the defining of standards and their implementation across the organisation.
There are enough guidelines and checklists defined at the organisation level to help project teams prepare for the code reviews. The same are used by the reviewers to evaluate the code quality. Also, SQA teams continuously work to identify the biggest trends in the industry, taking consent from the management; this is an ongoing process to keep them up to date with the latest changes. They also conduct regular education sessions to build awareness about these initiatives across the broader project teams on a regular basis.
As the complexity of the projects is increasing with the time to market coming down, it has become imperative to look out for alternatives to improve the quality rather than rely on the manual process. This has triggered the evolution of tools that can ensure broader coverage, improve time to market and, at the same time, align with the existing IDEs.These can also be deeply integrated with the build process such that the triggering of these reviews can be scheduled and performed in line with the build schedule, without manual intervention.
Selection criteria
After understanding the need for a code review tool, the next question we need to address is how to select this tool and what is the criteria we need to follow to assess the various tools available in the market. Is open source an option?
Some of the following features need to be assessed prior to deciding on the right open source tool for code reviews.
- Coding standards and best practices
The tool should alert the team whenever there is standards violation, increased complexity, etc. By enforcing these quality checkpoints, there will be better readability and maintenance of the code. Though there are many things possible here, starting out with simple features and extending them incrementally is the recommended approach. - DevOps integration
The tool needs to have a rich API to interface with any other tools or technologies for effective automation and integration. It should work equally well with build integration tools like Maven and continuous integration engines like Jenkins. Also, there should be a provision to alert the success or failure of the build, with all the details required for possible troubleshooting. - Programming language support
The tool should support the wide variety of programming languages in use today like C, C++, Java, JavaScript, etc. There should also be a provision to plug in or configure this tool with the IDE in use, like Eclipse, JDeveloper, etc. - Bug detection
The bugs can be anything specific to typical coding standards and best practices, and sometimes even go a little deeper into security vulnerabilities. There should be a provision to enable project- or application-specific configurations and settings on a need basis. With all the digital options evolving at a rapid pace, security has become one of the important areas that need close monitoring. The tool should detect and arrest some of these security vulnerabilities early in the game. For example, the tool should never allow the hard coding of sensitive information like the Aadhaar number, IP address, etc, as part of the code. - Centralised quality
We are slowly moving towards an enterprise kind of setup for code reviews, where the rules configured from individual projects can be shared and reused across other projects to ensure overall coverage. Also, the best practices evolved over a period of time can be shared across the teams to benefit the entire organisation. The tool should provide enough options to dashboard the overall health, both at the organisation level (covering all projects) and at the individual project level. Also, the history gathered over a period of time should help in analysing the trends and patterns to define the path for continuous improvement.
Open source tools and options
Though there are many open source code review tools, to keep it simple, let’s pick a few of them like PMD, FindBugs, CheckStyle and SonarQube for analysis.
Most of these tools generally support Java, and some of them extend this to other programming languages too. They typically have a plugin option to integrate with the development and deployment tools. The rules-driven approach and configurable nature makes them more saleable, comparatively. Features like CPD (copy paste detector) help in identifying and applying fixes across the code, at one shot.
1. FindBugs is a Java specific tool with little or no support for other programming languages. To keep it simple and easy for developers, it has an Eclipse IDE plugin for seamless detection and identification of issues. The recent addition of the cloud storage feature allows distributed access of bugs across the teams.
2. PMD has support for more programming languages than just Java, like PL/SQL, XML, etc. It has the Eclipse IDE plugin and integrates well with Maven for Build creation. Also, CPD is an inherent and important feature, which can help in identifying and fixing the duplicate code consistently across the board.
3. Checkstyle is another Java specific tool that works well with Eclipse. Its easy integration with Maven and Jenkins makes it more attractive. The highlight of this tool is its flexibility in adapting to the various coding standards prevailing in the industry.
4. SonarQube is an open source platform that helps in automating the end-to-end code review process. The differentiator of this tool is that it supports many programming languages along with Java. Like other tools, it also has plugins to works with the Eclipse IDE seamlessly, and its easy integration with Maven and Jenkins makes it a little more attractive. The highlight of this tool is its ability to work with multiple projects in parallel. Its rich dashboard feature makes it easy for the leadership team to get access to all the possible insights. SonarQube can be accessed online as a service and has the provision to configure some of the security-specific rules as well.
Source code can be fed as input for a tool, which is analysed to get the output as feedback. For the given input, the tool scans the entire code for defined rules and configurations, and outputs the metrics in a feature-rich dashboard for user consumption. It can also provide good insights on how the code is faring over a period of time, even comparing it to previous runs. This is to make sure that the journey is in the continuous improvement mode. Most of these tools have built-in rules, but they can be tweaked or extended with custom rules if required.
Challenges
Though most of these tools are rich in features, their real benefit can be perceived only if the tool is properly understood and configured; otherwise, there will be a risk of missing on leveraging the full potential. This challenge can be mitigated by having a dedicated team working on the features of these tools, with a constant eye on timely feature upgrades. Also, the same learning has to be propagated to the developer community on a regular basis to keep them updated about the changes.
Final comments
Overall, each tool has its own strong points based on the respective individual features. However, SonarQube has an edge over the others with its comprehensive feature list that covers support for multiple programming languages, access to a centralised repository and maintenance, duplicate code identification, easy integration with most of the development and build tools, and many more. Last but not the least, its rich dashboard feature makes it an obvious choice for both the developer community and the organisation. However, more than the tools, it is the discipline which has to be inculcated and maintained in the teams that makes the entire code review process effective. The tailoring of the processes can be done based on the individual situations, but should be arrived at after taking all the stakeholders into confidence.
Note: Views expressed by the author are his own and presented here in his personal capacity. These are in no way representative and/or reflective of the organisation he is associated with.
