What is code review?

Code review is systematic examination (often known as peer review) of computer source code. It is intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills.

Why is it important?

• We all are human beings. You may do some mistakes irrespective of your experience in a particular technology or module. If you just review your code by a second eye, those mistakes might caught at that time only. This way you can reduce the number of bugs reported by the testers or end users.
• If you are working in a geographically distributed team, your coding conventions may differ and if you have some strict coding guidelines, this code review process will make it possible to recheck the standards in the code that you have written.
• There are some possibilities of repetitive code block which can be caught during a code review process. Refactoring can be done based on that.
• Unused code blocks, performance metrics etc. are some additional check points of doing a review.
• If you are new to development, this code review process will help you to find out your mistakes and help you to improve them. This is a perfect knowledge sharing mechanism.
• Find out the defects and correct them at the beginning before it commits to the source control system.

How we do code reviews?

• Don’t micro-manage: Don’t force your team to review every changeset, nor to follow a rigid process during the code review. Remember: agile code review is mostly about knowledge sharing! All other things are good side-effects.
• Encourage asynchronous reviews: Code review meetings take your developers away from their work, breaks their flow and will be met with resistance. A better approach is to enable them to review code when it’s convenient, the same way they read email, RSS feeds, etc.
• Actively share interesting findings, constructs, design decisions via code review – be the champion: Build an easily accessible knowledge base from your code reviews.
• Treat code review as yet another state in your project workflow: Don’t wait for code review until the end of the iteration. Late code review is often worse than no code review at all – it’s often tool late to react to the findings. Instead, treat code review as one more step between ‘To Do’ and ‘Done’, so that it happens constantly throughout your iteration.