Top 5 Code Review Mistakes
Top 5 Code Review Mistakes
“To make mistakes is not a mistake, but repeating mistakes is definitely a mistake.” Click To TweetWith that said, one way to spot mistakes in the code produced and to improve the quality of the same is through the means of code review. Code review can be understood as a systematic process of evaluating and checking the code produced at the development stage. This analysis of the code is an ideal way for the written code to be seen by four or more eye principles offering a wide array of perspectives and opinions.
Different organizations and people have different definitions of code reviews. It is not a stringent, fixed process that demands a proper format or mechanism. Trial and error is the key! You need to figure out what works best for your company and your employees. Code review when done precisely, to exploit its full potential can enhance the overall quality of the project. With this, there also comes a risk of a few mistakes that one should look out for while reviewing codes. Well, to make things easier, we have compiled a list of some common code review mistakes that you should be aware of.
.
Common Code Review Mistakes
1) Hop off tests:
Hopping off tests or skipping tests is one of the greatest mistakes one can make. A review contains various tests and reviewing all of them can get mundane. The process of setting-up, asserting, and tearing the code down, again and again, can get boring. This recurrence puts us off-guard pretty soon and forces us to jump to assume that the rest of the tests would be perfect. Even though that is never the case! A few tests slip away through the code reviews exposing the entire project to risk. To run off from the extra effort, developers generally have a quick look at all the tests and directly hop onto implementations and conclusions.
Tests are also codes that should be reviewed to understand its working and functioning. Ignoring the fact that reviewing tests requires a great deal of focus and understanding, it comes bearing a lot of benefits. For instance, the detection of bugs early in the process is better, as bugs cost more the later they are identified. Hence, code reviews are meant to be a systematic review of programming source code, aimed at rooting out errors made in the original development process and improving the quality of the software being developed.
2) Reviewing only newly added codes:
Code reviewing is a constantly evolving process that goes through various phases of changes. During the process, there may be times when certain lines of the code may be deleted or just ignored because they may be old. What developers tend to ignore is that the code produced is like a well-knit story that has to be read all at once. When you start reading and acknowledging the code in parts, you leave out certain details.
While reading a story, you probably do not like skipping chapters or jumping paragraphs because you may lose the concept. And so is the case with codes! You need to think of codes as an entire, whole story that cannot be broken down in parts or read in parts. Another common mistake spotted here is that developers review the lines of codes that are recently added to the codebase and they leave the already existing ones. One should not practice this as again the code has to be seen as a whole, single package.
3) Rush:
A proper code review not just requires time but also requires peace. A rushed review may tend to compromise on the quality of the code. A few minutes before the demo, release, or deadline is the worst time for a code review. What generally happens in these cases is that the reviewer just reads the code lines rather than reading the codes through the lines. Regardless of whoever’s fault, it was, a poorly-written code has been incorporated in the codebase which would thus affect the entire project. To avoid the same, it is always a better idea to close your work well in time before the presentation or demo.
Only if you manage your time and work properly, you can get enough time to look into changes or corrections. Hurried reviews can even miss out on fine and subtle mistakes. Another option that would come to your mind is the use of automated review which will definitely reduce human error but still, a rushed or hurried review is never a great choice.
4) Ignoring Design:
Another major mistake that reviewers do while reviewing the code is that they ignore their role in the entire process. The responsibility of the reviewer to look at the entire code thoroughly, from its design to its language to its mechanism to its working. Many times, reviewers ignore the design of the code and concentrate their focus on the functionality and the workability of the code. But reviewers need to think carefully about the role of the code in the framework in order to understand how it blends with what already exists.
Reviewers should acknowledge the impact of the changes if any on the overall architecture of the code. Most of the changes will not affect it, but those that are important and critical can demand close consideration and observation. In such cases, it is best to consult with the other team members and understand the varied perspectives they have.
Must Read: Five Tips That Will Help You Become a Better Code Reviewer
5) Unclear Comments:
Dropping unclear, obscure comments in the comments section for the author of the code is another major mistake that reviewers make. It is not helpful to comment in a monosyllabic fashion such as, “Please Fix” over something you do not like or agree with. How would the developer understand what you meant by that? Maybe the developer would figure it out, maybe they do not have enough expertise to fix it or maybe they do not think anything needs to be fixed. Before you explicitly articulate what is wrong with a given fragment, you cannot be certain as to whether the developer has understood what you meant by it.
The reviewer should make it a point to give out accurate, understandable remarks. You should be specific and precise with where and what you feel is wrong. To build space for conversation, it is important to put in direct comments. You need to identify concerns and suggest some ideas in order to build some space for dialogue. There are no grounds for debate or a change of mind without them.
Conclusion
Ultimately, derailing a code review causes more work for everybody, the developer, the reviewer, the entire team. Problems or mistakes in the code review cannot just impact the entire work climate but can also poison the team. The above-mentioned list of common mistakes makes you aware of some of the mistakes that you may commit as a developer or a reviewer. Code reviews might not always be fun and enjoyable, but they are very important from a professional point of view.
Code review is an exceptional method, one of the most valuable. You may use it to enhance the consistency of a certain code, confront your team about something and discuss it or just pass on your information.
Codegrip offers you a flawless automated code review system. Get in touch today to know more.
