Code reviews are a vital part of software engineering, where you examine and improve the quality, readability, and functionality of your code. They can help you catch bugs, enforce standards, share knowledge, and learn from others. But how do you conduct code reviews effectively and efficiently? Here are some tips and best practices to follow.
Before you submit your code for review, it is essential to ensure that it is ready and meets the requirements. This includes testing your code thoroughly and fixing any errors or warnings, formatting it consistently and following the coding style guidelines of your project, writing clear and concise comments and documentation, breaking the code into small and logical chunks that are easy to review and understand, using descriptive and meaningful names for your variables, functions, classes, and files, as well as removing any unused or redundant code, comments, or imports.
Automated tools will help in preparing your code. Too many times I've seen organizations that skimp on developer tools which leads to dirty code hygiene. Linters, unit tests, and integration tests running CI pipelines will help to keep code clean and reduce bugs. This will alleviate your developers to focus on solving problems rather than proper code formatting.
We can integrate various tools that ensure: 1. Unit tests are run and passed 2. Code doesn't have warning (build with warnings flag on) 3. Security/vulnerability is checked 4. Memory leaks are checked Code must be commented well and used proper naming conventions.
When selecting reviewers for your project or workflow, you may have a designated team, a peer, a mentor, or a random reviewer. It is important to ensure that they have enough time and availability to review your code promptly and thoroughly and that they possess enough knowledge and experience to provide constructive and relevant feedback. Additionally, they should have enough context and background to understand the purpose and scope of your code, as well as enough diversity and perspective to offer different insights and opinions.
We often have a tendency to choose reviewers who are like-minded (especially in design style) who are unlikely to have philosophical disagreements with your code. However, this may result in less scrutiny of your code, and thus your code quality might not be as high as it could be. Being forced to hear and consider more aggressive or controversial feedback at least gives you the opportunity to consider other perspectives, which could result in a better design. Don't rob yourself of the chance to make your code the best it can be by addressing different viewpoints from more challenging reviewers!
We should identify 1 or 2 mandatory reviewers (module owner/expert) and few optional reviewers. Enforce that code can't be merged without go ahead from mandatory reviewers.
Ensure that the code review involves relevant team members who have the necessary expertise in the area being reviewed. Clearly state the objectives of the code review. Are you looking for code correctness, adherence to standards, performance improvements, or all of the above? Be specific about what the team should focus on during the review. This helps in providing valuable insights and relevant feedback.
Communication is essential for successful code reviews. Before, during, and after the review process, you should provide a clear and concise summary of your code, its objectives, and its dependencies. Additionally, explain any assumptions, decisions, trade-offs, or challenges you encountered while writing your code. Specify any areas or aspects that you want the reviewers to focus on or ignore. Additionally, it's important to respond to the reviewers' comments and questions promptly and politely, as well as acknowledge and appreciate their feedback and suggestions.
Communicating clearly with your reviewers is important, but it's also important to communicate early! Once you have designed your architecture or implementation plan, talk to your reviewers about it informally before you start coding! Why put in all that hard work writing, debugging, and testing code if the reviewers are going to insist on big changes later? By getting reviewers familiar with the architecture in advance, when it comes to the review itself, they should not be surprised. By aiming for a 'No Surprises' review, the reviewers are much more likely to see your work as a valid implementation of the architecture they have already seen. You will develop a strong reputation for outstanding work with easy reviews.
The traditional code review is a waste of time. The reviewers come to a meeting (euphemism for interruption) straight from the printer carrying a pile of code they are seeing for the first time, incidentally wasting a lot of paper. Since they don't see the code in context, they focus on minutiae and quibbles. The traditional code review does not work. I review code on my development machine. I pull down the branch, review the code in GitKraken and sometimes debug through it. I do this at a time of my choosing, I waste no paper, and I leave comments and remarks that are persistent, not just remarks in a meeting that someone writes down. Maybe. I review all checkins, not only those in my own area, unless I am on an operating system.
Encourage discussions about design decisions, especially if there are different approaches to solving a problem. This promotes knowledge sharing and can lead to better solutions. Foster a positive culture where team members feel comfortable giving and receiving feedback.
As a reviewer, your role is to evaluate the code and provide feedback that helps the author improve it. When reviewing, you should maintain a critical and objective eye, yet show empathy and respect for the author. Focus on the quality, readability, and functionality of the code, not on style or preferences. Aim for a balance between positive and negative feedback, highlighting both the strengths and weaknesses of the code. Use clear and concise language to explain your reasoning and provide examples or references. Lastly, maintain a constructive and actionable tone, suggesting specific changes or improvements.
As a reviewer you can take that extra step to pull and run the tests locally. Look through the tests first to see what scenarios are being covered. Are the tests just covering the happy path? What about edge cases such as null or empty values, or proper error handling? These are then topics to discuss directly with the developer to ensure you have resilient code.
First thing that I look in a code review is that is it documented and written in such a way that a new engineer can understand the code with least effort few years down the line. All the assumptions and core logic should be documented. Code should use proper naming conventions. Focus on catching issues that can't be easily caught in unit testing like out of bound errors, memory leaks, loop boundaries etc.
Start with Automated Tools: Utilize automated tools and linters to catch common style and formatting issues before the code review. This saves time during the review process and allows reviewers to focus on more substantial issues.
As an author, it is your responsibility to receive feedback and apply it to your code. You should do this with an open and receptive mind, while still being confident and exercising good judgment. Additionally, you should approach the feedback with a willingness to learn and improve, rather than to defend or justify your code. It is also important to have a collaborative and negotiating spirit, rather than engaging in confrontation or argument. Finally, you should show respect and gratitude for the reviewers' time and effort, instead of feeling resentment or frustration. Additionally, you should verify and confirm your changes through testing and documentation.
The golden rule to remember: Code reviews are not personal! It's a collective effort between the author and the reviewer to work towards a shared goal -> To write efficient code to solve the problem in the most optimal way.
Use questions as feedback. If you take an aggressive or overbearing tone, that may squash the spirit of your fellow developer! Think of the feedback process as a time to question assumptions in the code changes. It's a collaborative effort.
Code reviews should not be a one-time event, but rather a continuous and iterative process. To ensure the success of this process, you should implement a feedback and evaluation loop, document and track the code and reviews, and celebrate and recognize the reviewers and author. This will help to ensure that the review process is effective and that everyone involved is recognized for their contributions.
In addition to code review by the peers some code quality check tools can be used to improve the code quality and take care of code smell. Tools like Sonar Cube and add on on IDEs like sonar lint and tslint are very helpful in this direction.