Rules For Code Reviews In Software Development

Code reviews are important in any software development processes to ensure the late failures of the software systems. Though code review does not add any value directly to our customers, its indeed required since the review is second level of confidence on the implementation work. There are different types of code reviews. While static code reviews ensure the syntax and coding guidelines correctness, the reviewers review code for correctness of the program logic and affected code areas. Following are some guidelines that people can pick based on what works best for them. The guide  lines vary among different software development teams and there are no rigid rules.

In this post I'm going to write about the code review guidelines and some best practices that we can follow during code reviews.

1. Avoid checking-in the code that is not reviewed. This is because in a bigger software system, any change made can have impacts on other software modules. Have the code at least peer reviewed.

2. Reviews can be piled up if the reviewer is not available and number of reviewers are less compared to developers. When I say 'reviewer' it means that some one who understands the system as a whole and knows the system architecture. This helps finding the impacted areas of the code changes. In this case files can be checked and then the revision numbers can be noted down and sent for the review.

3. Code review is challenging because, the review expertise comes from experience dealing the software systems and code review requires domain knowledge too. Based on the nature of the software i)Software Product 2)Software services. 

4. Checklists play a great deal during the code review. The review checklist can be customized based on the type of software. For example, does the code change impact xyz module? Does the change takes care of backward compatibility.

5. Let the code not lie local to a system for more than 3 days simply because its not reviewed. Its fine to check-in the code if the review is getting delayed to make sure that the work is not lost.

6. Checked in code can always be reviewed before the new change goes to the production and hence there is no harm checking in the code that is not reviewed. It only requires to ensure the reviewer does review the checked in code without missing any revision.

Sometimes the code review involves going back to the design and seeing if the code is written as per the design (if the design is present).

Code review is not for testing somebody's programming skills and suspecting some body does not write better code because any developer's, even experienced one, can go wrong in a complex software system. And hence ensuring code reviews (not for just following the process) is essential to get better code quality.