Tips for a successful code review

Code review is a phase in the software development life cycle (SDLC) where the author(s) of the code, review team and possibly quality assurance (QA) come together to review code. Here are some tips for a successful code review

Mix of Three reviewers:

Who should review the code: A balanced code review team is a mix of:

1. A hands-on software developer, typically a peer of the contributor
2. An architect who is aware of the software' future direction
3. A project lead who can weigh the compromises between time-to-market and the future needs of the software during the review process

Four instructions for the Review

1. Set clear objective and perspective for the review. A focused review is an effective review. Spend time at the beginning to set clear objective for the review. One could set different objective to different reviewers to cover the review in all perspective. A set of reviewers can have an objective of reviewing the code from the architecture point of view while another set of reviewers can have an objective of reviewing the code from an optimization or scalability point of view.
2. Set a time limit for your review. During your code review, one might find that the details become overwhelming, and may lose track of the higher-level details that you are looking for. Set a reasonable time limit on your review, and then optimize your review for this limit. If you find yourself spending too much time in any one area (especially if it is not a high-priority area or objective), flag it for later review and move on. Make sure adequate time is allocate for the review
3. Use the question list. Use a question lists to help ask the right questions to identify problem. The question list is a listing of questions like : Are exceptions and error handling taken care?
   Is the code scalable?
   Are boundary conditions taken care?
   What will happen if the parameter is negative?
   What will happen if there is an over flow condition?
   Does it adhere to coding guidelines?
4. Review incrementally and iteratively. Limit your reviews to small, manageable pieces of code. This allows you to finish quickly; stay focused, and find a larger number of issues in the code you are examining

Five rules for Reviewers:

1. Code review should not be a fault finding operation - but is meant to highlight a better way of solving the problem
2. Input for conceptual: Use Requirements document as an input for getting the conceptual picture of what the code is trying to accomplish
3. Input for details: Use Design document as input for getting the specific details of what the code is meant to accomplish
4. Input for coding guidelines: Use a set of coding guidelines. This is often lesser use to a human reviewer and of more use to a tool.
5. Code review should focus on small chunks of code and should have the objective of assessing the overall solution.