Code Review and it’s Importance


In this post, I will discuss about Code Review process and it's benefit. I am dedicating this post to all the developers. - Article authored by Kunal Chowdhury on .

As a developer we all write lots of code, we all try to write better code in our module and want to keep away those freaking bugs that pops up by the testers. Isn’t it? Then what is the need of doing a code review and spending those extra time for just a review process?

 

Whole day everyone is busy with their module, so who has the time for this unnecessary work? Is it really unnecessary? Let’s check it out in today’s blog post. I hope, you are excited to read it.

 

We might be working in a team located in a single building or distributed geographically. Developers write code for their individual module, test it and then check-in those code to the TFS or any other Source Control Repository. There might be an automated build server that has been configured to find out any compilation issue and then that creates a package and send it to the automated testing server on successful build.

 

If those are already configured like the way it should be, what is the importance of code review? It is not only the code review but a review of the whole process from the requirement analysis to deployment & testing. Everything should be properly reviewed by a peer team member or an individual to reduce the no. of defect or cost per defect.

 

Why we do a Review?

Code Review to Reduce Cost Per DefectA general analysis report says that, if we do review at the earlier stage, the cost to fix this will be less and thus it will reduce the overall cost of the application. It is 2400% cheaper to fix any issues in development stage than in the production environment.

 

The graph shows you how the review process effects the cost per defect in different stages. If you do a proper review in the requirement analysis stage and start implementing the code in proper way, you will see a less no. of defects. But if you find the defect at the later stage during or after the deployment, there will be more chances of complexity of the bugs and the cost to fix them will be very very high than resolving them in the initial state.

 

The same applies to code review process too. If you are working on a module, each and every part of the module needs to be reviewed by somebody to check the defects in it’s earliest stage. This could be naming convention, repetitive code block, unnecessary codes, performance measure and other minor or major defects.

 

Advantage of Code Review

Better code always starts with review process. It highly measures the quality of the product. As I mentioned earlier, the cost per defects highly impacts if we do a review process at the earlier stage. There are few major benefits of doing a code review:

    • 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 no. 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.

There are lot more benefits of doing a code review which you will experience when you go through a code review process. If you are a reviewer or if you are the author of the code, in both the cases you will learn from the other. But in general, the author gets more chance to learn from the reviewer.

 

How the Code Review Process Works?

Everything has it’s own Life Cycle, the same applies to Code Review process too. A developer ones finishes the coding stuff of a particular module or task, sends that piece of code for a review to a dedicated code reviewer or a person within the team for peer review.

 

The reviewer pulls few minutes from the work schedule to review the code written by the other developer and provides comments to fix the issues noticed during the process. Sometime the reviewer also checks the execution of the code and provides suggestions during the review.

Code Review Process

If the review process produces any comments, the developer fixes those issues and sends requests for another set of review with the latest code. The reviewer again checks the code and provide additional comments if any with the new code. Once the process completes, the developer is ready with the code to check-in to the repository. This ensures that the quality of the code that is going to check-in to the system is good.

 

Problems with Code Review Process

The developer and the code reviewer

The major issues that will arise when the other member who is going to do the review of the code is not first enough. The author of the code does not have free time, he has to do lot more stuffs. So, the reviewer should be prompt enough to check the code for any defects.

 

But that does not mean that the reviewer should neglect piece of code to reduce the effort. This may produce a big hole. The reviewer should be smart enough to find out the defects with the code and provide informative feedback to the author of the code and the author should accept those changes and remember while writing code in future.

 

Another important issue with the Code Review process is, the developer throws the ball to the reviewers court without doing any self review. In some case, the developer knows that it's an issue but still wants to catch it by the reviewer. In such case, if the reviewer misses the block, it's an Golden Ball from the author of the code. He also misses the same though he knows. If something that you can check, why to wait for other to report it?

 

For example, look out the cartoon attached here for an interesting story. Remember, this could be a possible bug in the production and may impact your project in future. This small negligence could be dangerous in the coming days. So, make sure to review your code yourself always before sending it to reviewer for an additional check.

 

What’s your opinion?

As we discussed more about the review process today, I just want to know your opinion. Are you going through such process in your work? If so, what’s your real time experience with this process? Is it beneficial?

 

If you didn’t yet following code review process, try it at least once and see the difference. As I already said, we are human beings and hence silly mistakes can be possible knowingly or unknowingly. This review process will find out those mistakes and help you to learn from the other who just reviewed your code.

 

Whatever the case, let me know your thought and/or feedback if any which will help the other to understand it and also help me to improve this post. Yes, this is also part of a review process where you are the reviewer of this post and I am the author. So as expected, I will wait for the review comments, Smile right?

 

I am available on Twitter and Facebook where you can connect with me and say a “Hello” too. Don’t forget to subscribe to my blog’s RSS feed and email newsletter. Enjoy!!!

Have a question? Or, a comment? Let's Discuss it below...

dhgate

Thank you for visiting our website!

We value your engagement and would love to hear your thoughts. Don't forget to leave a comment below to share your feedback, opinions, or questions.

We believe in fostering an interactive and inclusive community, and your comments play a crucial role in creating that environment.