Code Review Plan-Java Application

Version 1.0

15-Jan-2014

Java Application Code Review Plan

Page 1 of 8

Java Application - Code Review Plan

1. Scope
This document provides an overview on Code Review planning for any java-based applications. This document will discuss varies approach and tools that will be utilized for Code Review. The document contains Code Review plan steps and tools description.

2. Code Review
Code review is the process of analyzing the source code of software and reporting the deviations from coding standards. Code Review finds the varies coding mistakes such as probable bugs, style issues, readability issues, performance impacts, deviation from the global coding standards etc. Code review report also suggests different ways for improving performance. Code review helps the Lead developer to reduce bugs and performance impacts due to common coding mistakes. Code review will not be able to reduce complexities that arise due to design issues. Some of the items that suggested by the Code review report may not be fixable due to business requirements or dependency to an external system.

3. Code Review Methods

This section briefly explains the varies core review methods and steps Compilation Unit wise Code review and fixing During the development of each compilation unit (Java files) developer must perform code Following steps describes the steps developer need to follow. Step 1: review.

1. Import custom CheckStyle Rule set (optional) While in RSA, click on the menu item Help/Software updates/Available Software. Clock on Add Site Button. Enter http://eclipse-cs.sourceforge.net/update in Location TextBox. Expand added node and Expand Eclipse CheckStype Plug-in node. Select Eclipse CheckStyle Plugin 5.0 Click on Install button. Restart RSA. Download the file ExampleJavaCheckStyle from here
ExampleJavaCheckStyle.xml

Click on menu item Window/Preferences Select Checkstyle and in right pane Click on New button. In dropdown select External Configuration File. In Name Textfield enter ExampleJavaCheckStyle

15-Jan-2014

Java Application Code Review Plan

Page 2 of 8

Click on Browse button and select ExampleJavaCheckStyle file.in C:\temp and click on Ok button. Select ExampleJavaCheckStyle and click on Set as Default button. Click on OK button. Right click on folder and select CheckStyle/Check Code with Check Style.

Once the setup is done, developer is ready for Code review.

Step 2:
After completing the unit of work in RSA 1. 2. 3. 4. 5. Right click on the Java file in Navigator / Project Explorer Select Software Analyzer > <<ProjectName>> Software Analyzer Result window will appear. Select Java Code Review Select each items and inspect the error. Right mouse click on each and check whether Quick Fix is available. If yes then try to fix the same. Then inspect the fixed code and see whether the fixed code did not change the actual requirement 6. If Quick fix is not available, try to fix the item manually. Developer should ask for assistance from lead developer, if the change is too complicated or it may affect the core concept. 7. After fixing each item repeat from 1 to 6 until there are no more items left in the Java Code Review list. Developer should notify the lead developer if an item cannot be fixed. Step 3: 1 2 3 4 5 Checkstyle analysis Format the File. ( Make sure that your format template is Example Java Format ) Remove unused import using the key combination ctrl+shift+o Right Click on the Java File in Navigator / Project Explorer Select Checkstyle > Check code with Checks This action will display Checkstyle errors or warnings will be displayed in the source code itself. Developer can fix the Checkstyle errors and repeat the Steps 2 and 3, until there are no more checkstyle errors reported.

Enforced Auto Code review and reporting during install Code review reporting can be automated and enforced by configuring the Maven build file. Checkstyle, PMD and findbugs Maven plug-ins available, and can be configured. The plug-in goals will be added in to the pom.xml of the parent project so that these goals are executed in the installation phase. This make sure that code review is done and report is generated, even if code review is not manually performed. Once the install goal is complete report files will be created in target\site folder. This can be reviewed and issues can be reported to developer. The pom.xml can be configured to run varies tools and generate a report on the parent projects folder.

15-Jan-2014

Java Application Code Review Plan

Page 3 of 8

Configuration details This configuration need extensive knowledge about maven and it is assumed that Maven is used for build and dependency management. Each project will have pom.xml file as Maven configuration file. Add the given configuration xml code inside the parent poms Build> Plugins node Note: This following step (a) is not required if you have checkstyle plugin installation already done in RSA a) Checkstyle <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-checkstyle-plugin</artifactId> <version>2.5</version> <configuration> <enableRulesSummary>false</enableRulesSummary> <outputDirectory>${project.parent.basedir}\target\site\${project.name}</outputDirectory> </configuration> <executions> <execution> <id>checkstyle_install</id> <phase>install</phase> <goals> <goal>checkstyle</goal> </goals> <inherited>false</inherited> </execution> </executions> </plugin> . The reports for each and every project will be generated inside the parent projects target\site\Child project name. Hence the Lead and build the parent project and view all the child projects report. When a Developer builds other child project individually the report will not be generated.

b) PMD <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-pmd-plugin</artifactId> <version>2.4</version> <configuration> <targetJdk>1.6</targetJdk>

15-Jan-2014

Java Application Code Review Plan

Page 4 of 8

<outputDirectory>${project.parent.basedir}\target\site\${project.name}</outputDirectory> </configuration> <executions> <execution> <id>pmd_install</id> <phase>install</phase> <goals> <goal>pmd</goal> </goals> <inherited>false</inherited> </execution> </executions> </plugin> PMD will give static analysis and provide less detailed report. It is efficient to understand common coding mistakes and code quality. c) FindBugs <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>findbugs-maven-plugin</artifactId> <version>2.3</version> <configuration> <threshold>High</threshold> <effort>Max</effort> <outputDirectory>${project.parent.basedir}\target\site\${project.name}</outputDirectory> </configuration> <executions> <execution> <id>findbugs_install</id> <phase>install</phase> <goals> <goal>findbugs</goal> </goals> <inherited>false</inherited> </execution> </executions> </plugin>

The threshold value can be changed to adjust the bug severity to report.

Build wise Code review and reporting Even though code review before Check in is generally appropriate, it is also suggested by this document to perform a code review days before each build or release.

15-Jan-2014

Java Application Code Review Plan

Page 5 of 8

Before each build the code review should be completed by the Leads and there should be enough time for developers to complete the suggestion by the code review report. In this type code review entire application source code must be reviewed using Static Analysis tools. Following steps are suggested. Step 1 Make sure that not even a single document is in checked out status or hijacked mode. Update \ Synchronize the entire code from change management system such as Clear Case. Step 2 1. 2. 3. 4. 5. 6. 7. 8. Open the projects in RSA In RSA click Run > Analysis Under the configuration make sure that you selected <<ProjectName>>. On right hand side click on Revert to deselect the project which are already selected. Choose Analyze selected project and check all the projects that you currently doing code review. Click Apply and the Analyze. Wait till the Analysis completes. Open Window > Show View > Other > Software Analyzer Results if it does open up automatically.

9. Click on the icon pictured as and select Java Code Review Results and select PDF Report. 10. Distribute the file to people concerned. The main disadvantage of this tool is that it will generate report only on the basis of categories and not based on package or compilation unit. Hence report will only provide overall bugs statistics of entire project or code base. Manual Code review, reporting and follow up Before each build it is mandatory to perform manual code review on the application source. This is time consuming and difficult if aim for total code review. The strategy for effective manual code review is 1. Avoid all UML or Web service tool generated classes from manual code review. 2. Identify and maintain a list of source files or package which requires constant changes and prone to errors. 3. Identify and maintain a list of source files which has reasonable complexity. 4. Keep inventories of files having most lines of code, if these files changes before build then arrange for a code review? It is possible that these sources contain bugs dues to complexity. 5. Use a common set of code review check list and make sure that each item in the check list is followed to completion. 6. Standard check list document is attached in the reference section.

3 Code Review Tools

15-Jan-2014 Java Application Code Review Plan Page 6 of 8

4.1 Rational Software Analyzer, RSA Rational Software Analyzer is software which is integrated with RSA. This Software can perform static analysis of Java source code. The rule set used in this software can be configured to avoid unnecessary or irrelevant bug reporting. It is possible to export the result of the analysis as a PDF document. 4.2 Checkstyle A development tool to help programmers write Java code that adheres to a coding standard. It is possible to configure the checkstyle to cater the need of coding standard. Checkstyle can be downloaded from http://checkstyle.sourceforge.net/ . This is an open source and free software. 4.3 Findbugs An open source and free static analysis tool. Findbugs have Dataflow checking mechanism which can warn possible NULL pointer scenario. findbugs can be downloaded from http://findbugs.sourceforge.net/ 4.4 PMD An open source and free static analysis tool. PMD can find unused imports and other coding style issues and bugs. An analysis of PMD and Findbugs can be found at http://www.cs.umd.edu/~jfoster/papers/issre04.pdf Alternatively, PMD can be downloaded from http://pmd.sourceforge.net/

5 Code Review Process

Frequency and steps of Manual Code review Manual code review process should be performed every week by the person responsible. The reviewer should take the latest source from the Clear case. Reviewer should review codebase or project assigned. Reviewer should follow the checklist available in the project SharePoint. This should be done if and only if there is any recommendation by the reviewer. The link of the document should be sent to the developer who is currently working on the reviewed code. Escalation process Once the developer receives the review document, developer should fix the reviews within two days. Once the review is fixed developer should update the document and inform the reviewer. In case the developer did not fix the review, reviewer can escalate the non compliance to the Manager. Responsibility Technical Lead and or Quality controller is responsible for manual code review. Codebase or project responsibility can be shared based on mutual agreement between Technical Lead and Quality Controller. Project plan should be updated with the responsibility once it is decided . Automated Code review process During every installation of parent project an automated code review is initiated by Maven. The check style, findbug and PMD plug-ins generate report and store it in to respective project folder in the parent project target folder. This installation should be carried out by the person responsible and go through the same. All the high severity bugs should be sent to the developers.

15-Jan-2014

Java Application Code Review Plan

Page 7 of 8

Frequency of installation and report generation Installation and report generation should be performed two days before the Dev build, so that developers get ample time to fix the bugs. Fixing the review Even though the code review is automated the fixing is not automated. Quality controller will be installing the parent projects and check the code review reports. All the high severity bugs details will send to all the developers. Individual developer who is responsible for the file or module should fix the review. Quality Controller should rebuild the projects just before each build. If there are still severity bugs, quality controller should escalate the bugs report to Manager. Responsibility Quality controller is responsible for generating the report and developer is responsible for fixing the code. Frequency of Code review The code review should be done two to three days before the build so that developer gets ample time to fix the same.

15-Jan-2014

Java Application Code Review Plan

Page 8 of 8