What is code review?
In its simplest definition, a code review is a process where a code is reviewed by someone other than the author of the code. It is the systemic examination of a source code by a reviewer. This involves finding bugs in the code and improving code quality.
Code reviews can either be formal or lightweight (informal). Formal reviews, like the Fagan inspection, are time consuming, expensive, and very thorough. The review quality of formal inspections are high.
Informal or lightweight reviews cost significantly less and does not involve strict roles and the same amount of time that a formal review does. Reviews can be tool assisted, done in pairs, or as walkthroughs.
Why code review?
Code reviews are done as quality checks to newly written code or to code updates. It also allows developers to learn from their peers. Not everyone has the exact same experience and a code review is a chance to learn new techniques from colleagues. A code review can be viewed as a chance for knowledge transfer. It also saves time in the long run as a buggy, unreviewed code that makes it to release will take time to fix. Especially if the bugs are not found simultaneously. It also fosters teamwork. Apart from the quality and time-saving implications, having someone peer review your code will allow you and your fellow developers to form a bond and create a culture of learning.
Tips and Best Practices for Code Review
Use templates and guides
Code review templates make it easier for you to get into review mode. These have guides on what to look for in a code review and code review guidelines. This helps you get started and be in the right headspace for your review.
Ask the right questions
You need to know what you are looking for in a code review. Is the code functioning like it is supposed to? Does it follow regulation? Does the design make sense?
Code review really is more than just an activity to look for bugs. It’s an avenue for learning and a way to check if everyone is on the same page regarding organizational regulation.
Pace yourself
There is a standard for code reviews depending on your organization. The usual standard is around 200 to 400 lines of code in 60 minutes. There is a good reason for this. At this pace, you have a better chance of catching errors than if you push for a faster time.
You should also take breaks. The more time you spend on your code review without breaks, the less chances you have of finding defects or catching quality issues. Your brain can only handle so much information in a given amount of time. So give your brain a break every hour or so and come back to the code review with fresh eyes.
Embrace positive peer pressure
Peer pressure is generally recognized as a bad thing. However, in code reviews this can actually work to your advantage. The knowledge that someone else will be going through the code they have written actually drives developers to write cleaner code. No one likes the feeling of having their mistakes pointed out to them. This is why the next item is so important.
Give constructive feedback
Be respectful and constructive when giving your feedback. In reviews, there will be arguments, usually over reasons why the author coded it one way and why the reviewer wants it written another way; or on which solution is best. Keep the arguments to the matter at hand, and the best reasoning or argument should win.
On the side of the reviewer, if the solution provided is as effective as the one you suggested, there is no need to change it. There is no point prolonging an argument just to get your way. When you provide a suggestion for change, make sure you have a clear and concise reason for it. And make sure that you listen to the author’s reasoning as well.
Accept feedback
On the side of the author, code reviews are a chance to learn from your peers. Take advantage of their feedback, ask for the reason behind their suggested changes not as a challenge but as an avenue to learn. Ask pertinent questions in a respectful manner. If there are disagreements, talk it over with the reviewer in a calm manner. Reviews are designed as quality checks and knowledge exchanges and it is best that they are treated as such.
Take advantage of automation
You can save time and energy when you use source code analysis tools. These tools are effective in certain facets of the code review, usually the code style and security issues. It can also detect bugs. It will not find all the errors for you but it will catch some. This saves you time and allows you to focus on deeper issues that need human intervention.
Have face-to-face conversations
When feedback is given through written comments and notes, it opens itself to misinterpretation. Written words often cannot accurately convey tone and mood. Even if the reviewer had written the comment with no intentions of being disrespectful, the author might feel otherwise. So the best way to avoid this is to have a face-to-face conversation. This way, both parties can communicate more effectively with little room for misinterpretation of intent.
Use checklists
There needs to be a set goal to a code review. A checklist with expectations and goals given to the reviewer will go a long way in helping to keep the code review streamlined and aligned to its purpose. This gives your reviewer a guide to what to look for in your code as well as save their time spent on the code review.
Concentrate on one task at a time
If you are writing code and then was assigned to do a code review, do not try to accomplish both at the same time. Depending on which task has higher priority, focus on what needs to be done first. Do not stop yourself in the middle of coding to review a peer’s code and expect to go back to developing in a short span of time. Finish your task first so that you can focus all your energy into doing the code review. Or if what you are writing will take more than a few minutes to complete, take a break first before tackling the code review. This gives your mind a chance to reset.
