New Approach for Code Reviews from Managers Perspective

The objective of code reviews is to ensure that the code can be easily enhanced to support future business requirements; code is easier to reuse and maintain. This document will give the insight on how to be a productive moderator for code reviews. One of the most important tasks overlooked in many projects are code reviews. The code can be defect free and work fine in production. The question is, as business requirements change, how flexible is the code to apply these changes? This document takes a different approach from regular code reviews. The focus is not on every line of code; but rather it uses question driven approach to help set the agenda for moderating code reviews from a managers perspective.

The goal is to identify potential issues and have developers make the appropriate changes before the initial project is completed rather than during the maintenance phase.
The best time to have the code review would be at the end of unit testing phase. It is recommended to have the following representatives participate in the code walkthrough:

1. Manager – Moderator
2. Developer – Presenter of code
3. Architecture
4. Business/QA

You should have at least 2-3 sessions, no more than 2 hours at a time and with at least two day gap between sessions. Take the time to review the information from each session and prepare new questions based upon specific findings. It is recommended to have meeting notes summarized and items identified for discussion outlined before the next session. This should be distributed to everyone on the team for review. Prepare a list of questions around one business objective. Set clear objectives for the review using the question-driven approach. The below questions are a starting point to consider prior to code reviews.

From the Managers perspective1, As new consumers integrate with the service, what changes are required to the code?
2. When new error messages are introduced, what areas of the code need to change?
3. If a new method needs to be introduced, what changes are required to the code?
4. Is there any hard coding logic? If yes, walk through the code and explain why.
5. How does the error handling work?
6. If new error conditions are introduced, what changes are required to the code?
7. When new attributes are introduced, walk through the areas of code that need to change to accommodate this? Focus on schema; Data Power transformation in addition to code changes.
8. Could the code be a bottleneck that prevents the system from growing to accommodate increased load, data and users?
9. Is the code in accordance with your companies standards?
10. Is the code written to prevent performance problems?
11. How does logging take place? Focus on program termination; normal and abnormal.
12. What type of database access takes place?
13. If changes are required to stored procedures; walk through the code?
14. Is there use of Dynamic or Static SQL? Explain why on your approach?Have the developer document the answers to the above questions and use them to create a maintenance “how to document”. This will help when there is a need to determine impact of change when new business requirements are introduced.From the Programmers perspective1. Is the code clear and easy to understand?
2. Will other programmers be able to maintain this code?
3. Is the code documented properly?
4. Could this code be reused in other applications?It is recommended that a projector is used rather than printing out code. Printing out code will make the walkthrough more difficult and less productive. Only print code when specific issues or questions require additional clarification. Use the prepared questions as a guide to determine if the code is modularized and can be easily enhanced to support future business requirements. For more complicated areas of code, have a technical resource review the code line by line. Have the developer give a 10-15 minute overview of the high level understanding of how the code is developed and organized to meet various service functions. Then use the questions that were prepared for the code review as starting point to dive deeper into the code. Be careful to stay focus on the agenda as it is easy to stray off topic. Most importantly, don’t point fingers at the developer if issues are identified. If the changes being made are significant, you might consider having another code walkthrough when complete.

There are two types of methods used in code reviews, the formal or independent. The formal method is where the code is presented by the developer. The question driven approach would be more effective and the code reviews would be faster. The independent method is where the code is reviewed independently, rather than have the developer do a presentation or be present. If the reviewer has questions, then the reviewer is responsible for seeking out the developer to answer the questions. This method will give a different perspective, a wider range of questions that would need to be addressed by the developer. The advantage of using independent method is that the code would be looked at with fresh eyes and less likely to have feedback based on assumptions. The disadvantage to this method is that the code reviews would take more time. Therefore, it is recommended to use the formal code method.

This methodology has been successful and has prevented potential issues very early in the process. Let me know your thoughts and feedback.