Every professional in the software industry must have always heard the buzz about code review. However, it has been an overlooked concept ignoring its advantages or misconceptions build around it. If you have ever thought of punching your keyboard with the following words, “What is code review..? How to conduct code review..? “, then I believe you have reached to end of your search effort. This blog shall enable the readers to understand everything that should be known about the code review process like what, why, and how about the code review. We’ll also create a checklist or a guide for code review to save your ample time from exploring through Google.
It is an integral process and an ongoing practice during the software development phase. It helps to identify defects and bugs before the testing phase. It is an agile process where pieces of source code are made available to the peers for inspection with an aim to catch bugs, highlighting mistakes, remove vulnerabilities before they form a part of the product.
Code review is a two-way conversation where both the author of the code and its reviewer communicate and learn from each other. Thus it can also be thought of as a knowledge-sharing process.
Code review is intended to find defects in codes and not in people. If misunderstood then the team starts hating the process and creates a conflict among code authors and reviewers.
Although it can find early bugs to a greater extent, code review does not guarantee or shall not be assumed that it will produce 100% bug-free builds without any testing and quality analysis. You should consider is one of the other tools for producing quality products.
Finding and correcting errors at the initial development stage is relatively inexpensive as compared to the more expensive process of locating and bug fixing occurring at the later stages of development. It helps intensely to develop quality softwares by early catching of mistakes and avoiding bad problems in the product. Software’s are developed by human and to err is human. Hence quite obvious reasons to have reviews. Also, the developers mostly depend on manual or automated testing to inspect their code and functionalities. Meanwhile, they are ignoring the great gift and skill of human nature: the ability to see and correct mistakes of others.
Consider a scenario when a junior developer joins your project team. Senior developer may do not have enough time to give him the best of the training or hand-hold the junior folks, since they need to be coding. Doing small and frequent reviews of the juniors developers will help him to learn on a great scale. Also, the senior developer can spend all his time in developing his code and spare 15-20 minutes a couple of times a day to review the code changes by juniors. This way the junior is benefitted from the regular feedbacks allowing him to develop as good developer and meanwhile the senior developer also does not loses much of his valuable coding time.
Not to forget how important it is for the organizations following agile methodology. Their revenue source depends mostly on delivering working prototypes on regular intervals. So it becomes very important and useful for such organizations to produce quality prototypes.
Code review helps in knowledge sharing between the author of the code and its reviewer. The reviewer is also aware of the complexity of the project, known issues and areas of concern in the code base. Thus the team gets a good knowledge about the product and the reviewer can help the developer to make a correct estimate of the future work.
There will always be a point in the organization to start the code review process. However, any change or a new introduction will always be resisted somehow. If the decision-makers of the organization support the innovation, collaboration, and continuous improvement process, then it’s an added advantage to get started. They need to be convinced about the ongoing and continuous improvement of the codes, their products, and also their employees.
Even if the decision-makers are not that forward-thinking or future-oriented, you can get started through a bottom-up approach. You can start with a few members or a team, prove the advantages of it. It will boost the productivity and confidence of the team and which will ultimately inspire others to follow the same.
Few members might not step out of their comfort zone or might resist because they might have had some previous bad experiences. It is not good to force them to follow the process. Try approaching to them and encouraging them by convincing them to give it another try by making the process simple and light-weight.
Do not kick start the code review process by enforcing with too many rules, pre-authorization and loads of formal documentation/reports. Too many formal rules will definitely receive a major push back from your team.
Do not micro-manage the team with every small change. Do not make a big team for reviewing one’s code. More the number of members, the more the time required for review and hence more the cost incurred. So it is better to have a small team of 2-3 members to have an effective code review.
The developers should not review more than 200-400 lines of code (loc) at a single stretch. The human brain’s capability to find defects beyond 400 lines might diminish.
Developers should take their own time to review the code. One should not spend more than 60 minutes at a time with the aim to complete the code review backlog on time. Short Breaks can be taken to refresh the mind as research proves that taking breaks from a task over a period of time can greatly improve the quality of work. Code review in small quantities at a slower pace for a limited time results in an ineffective review process.
You should have quantifiable metrics which helps you to judge how effective and efficient your code review process has been. Depending on these metrics managers can deploy further changes in the review process if needed.
It is important for the authors to annotate their code as it serves as a guide for the reviewers through the changes and reasons behind code modifications or specific usage.
The reviewer’s task does not end with just finding the defects. They should also track that the defects are actually fixed by the author.
To optimize the time and efforts of your team on code review it is highly recommended to use some automated code review tools.
It is commonly found that your team repeats the same mistakes over and over. A checklist proves to be an effective way to frequently made mistakes. The checklist reminds the author and the reviewers to look over something that might miss out during the code review and ultimately improve their coding skills.
It is quite easy and common to see defects in a negative context, however, each bug is actually an opportunity for the individual and team to improve their code quality. Reports generated from code reviews should be avoided in performance reports. Peer review can impact interpersonal team relationships. Hence it is extremely liable for managers to create a positive culture, a culture of collaboration, and learning in the peer review.
You can create your own checklist or many checklists are available online. I believe the below checklist is good enough for you to get started with the review process.
I would end this post with a simple note:
KISS: Keep It Simple & Stupid (Keep the codes simple and understandable)
DRY: Don’t Repeat Yourself (Avoid repeating your mistakes and re-writing same codes)
Want to build a powerful code?
Codegrip makes sure that every piece of code you write is free from bugs, code smells, and vulnerabilities.