Code review process:
- Design: we provided a high level over view of how to solve a problem. No code at this stage. Talk with fellow developer who is available and development manager. Benefits of early design review is getting input that a single developer might have missed. Re-design etc if required.
- Code it.
- Submit code/link to code changes to another developer for peer review via email/electronically. Best bet is to submit it to a developer who was not involved with design review. Note that the reviewer should review the code without input from the original developer. This is important. We approach it this way for several reasons. If the code can be understood by someone who has not written it then it is safe to say it is maintanable should the original developer be no longer around to ask (left the company or whatever) or even if they are. If the code reviewer cant understand the code then its given back to the developer and he/she makes it more understandable either by greater documentation or refactoring the code. It could be as simple as adding more information to the bug description that the code change is realted to. This in it self saves so much time in the future. The ability to pick up someone elses code and understand it quickly is very advantageous.
- Developer and code reviewer get together and discuss code/improvements.
- Developer makes changes if required.
Types of Code Review Activity:
1. Desk Review
2. Peer Review
3. Panel Review
4. Client Review
Desk Review /Informal Review:
1. As a Senior Developer/ team lead / Project lead can sit with developer in his machine and check the complex component implementation.
2. Review the naming convention, number of lines per method or class and for loop, if else ladder, Map or List or array usage and review the developer business logic understanding and implementation.
3. Provide the on the fly review comments to the developer to focus on the key implementation skeleton.
Peer Review:
1. As part of any logical component implementation completion, the developer can call for the Peer Review.
2. Peer will be identified with in his track/team and the code artifacts needs to be submitted to the peer by the developer
3. Identified peer will review the code artifacts against the coding checklist as well with the help of coding guidelines
4. Peer will provide the review comments to the appropriate developer and Keep the Team Lead/Project lead in the communication loop.
Panel Review:
1. Panel will be identified with in the project
2. Panel consist of Architect, SME, Lead, Senior Developers (max 5- 8 people)
3. End of Specific Service or Functionality formal component implementation completion, the code or deliverable will be submitted to the Panel by the respective track or team lead.
4. Panel member will do the offline review on the code/artifacts thoroughly
5. Panel needs to check the Implementation strategy, design pattern, reusability, QoS and the functional logic implementation.
6. Panel will gather in the Meeting room and the team lead /code owner will present the code to panel and walkthrough the artifacts.
7. Panel will raise the concern or identified gap in the meeting and the panel member will discuss the gaps.
8. Finally the panel will recommend the refactoring or approve the code for baseline.
9. All the review comments will be prioritized under one of the following criteria such as Development change/refactoring, bug, design issue, requirement missing, Change Request etc
Client Review:
1. After the panel review ,the code will be given to the Client Technical panel (if your project structure has this?) and receive their inputs for further beautification in your client deliverables.
Finally your project manager will take the summary of the code review metrics from the tool and use that for code quality metrics/ SLA Base line.
source :http://www.saching.com/Articles/What-is-Code-Review-Process-2121.html
