Effective Code Review Tips

We recently wrote a post about the importance of code review. Today, we want to offer a few tips and tricks for reviewing code effectively and efficiently.

Before we proceed to the tips, however, we should stress that the foundation for efficient code review is workflow planning. Effective planning should result in short but effective code reviews. If your code review procedures are burdensome, then it may be best to review your whole team’s workflow instead of focusing on an individual’s personal productivity.

Code Review Tip #1 - Code Review is For the Whole Team

Code review helps developers get familiar with code they haven’t personally written, learn from other’s mistakes, and discover new techniques. Everybody involved will take something different away from the process — but that’s precisely why everybody should be involved in code review.

We should note that some agencies have one group of developers write code and another group review that code, but there is a big downside to this approach. Separating code writers from coder reviewers can result in an ‘us versus them’ atmosphere, where code reviewers critique code writers as critics, not as peers

Code Review Tip #2 - Keep It Short and Sweet

Most developers say that a one-hour code review process is usually effective. We believe an hour is a reasonable upper limit. That said, if your review is anticipated to take more than an hour, it’s best to split the process into sessions and take breaks. Just keep in mind that a lengthy code review process is generally not that effective; try to decompose your tasks in your workflow into smaller ones, thus writing (and reviewing) smaller and more manageable chunks of code.

Here at RubyGarage, code review usually takes around 10 to 30 minutes. We assume that if more than 30 minutes is required, then we didn’t build our workflow properly. For instance, if we need to develop a user sign-in feature, we’ll split it into few small tasks: sign-in via social networks, sign-in via email and password, and resetting the password, for example.

Code Review Tip #3 - Don’t Review Too Much Code At One Time

Our experience shows that it gets pretty difficult to review more than 200 lines of code at once, and reviewing 400 lines of code is a nightmare. So take breaks during longer code reviews — or, even better, set up your workflow so that developers write small chunks of code to review. If you can’t break down your code into sufficiently small chunks for some reason, then another option would be to hold code reviews before all code is completed, perhaps even daily. More frequent code reviews will allow you to follow a developer’s progress and help your team avoid mistakes before they happen.

If your time is very limited and you can’t allocate the resources for a complete code review, popular practice is to check only 20-30% of the code written. In this case all developers will still keep their code in shape in case it’s called on for review, ensuring quality.

Code Review Tip #4 - Make a To-do List and Check for Common Mistakes

To make sure you don’t miss anything during code review, it’s a great idea to make a check-list of all the things you need to check. Every time we review code, for example, we pay special attention to the code’s security, business logic implementation, and user access rights. These items would be our starting point for any code review checklist. You might also have a list of common mistakes developers make so you make sure to check for them each time you review.

When we write code here at RubyGarage, we want to make it as readable as possible, and therefore we follow style guides for the languages we use. For instance:

• A community-driven Ruby coding style guide
• A Community-driven Ruby on Rails 4 coding style guide
• Best practices and coding conventions for the CoffeeScript programming language

We also write down some of the most common and anticipate mistakes in the internal documentation for each project, which is another useful practice for developers.

Code Review Tip #5 - Make It Painless

If you’re the one who’s going to submit code for review, be sure your code is crystal-clear and doesn’t require additional explanatory comments. When submitting, provide the necessary context for the reviewer so they can immediately dive into the code.

At RubyGarage, we submit our code for review through the Pull Request feature in GitHub. When using Pull Request, you should list the changes made to the code, and are given the opportunity to describe modifications if necessary. This additional documentation makes code review more effective.

Code Review Tip #6 - Define Code Readiness

Defining strict requirements for code that is ready for review is another component of wise workflow planning. Prior to each code review, our developers at Ruby Garage should scan their code for common mistakes, check if enough tests were written for automatic review, and verify that their code was written according to the relevant style guide(s).

We have a continuous integration server that checks every new chunk of code after its submission by running a series of previously written automated tests. Only if the code passes those tests successfully does GitHub indicate that it’s ready for manual review. This makes the whole development process much more transparent.

Code Review Tip #7 - Define Your Goal

The most obvious goal of code review is to catch mistakes. However, the goal for a particular review will depend on your current project timelines and the team rules. Are you laser-focused on how the code represents the required functionality, or do you also want to avoid code smell and make sure code adheres to the style guide? Often you may not have enough time for all of the above-mentioned goals, so you have to determine which are most important.Here at RubyGarage we try to write the best and most error-free code possible, because practice shows us that you rarely have time for refactoring or additional code reviews.

Code Review Tip #8 - Quantify the Effectiveness of Your Code Reviews

Managers always want to make processes more effective. But how can you make code review more effective? The best way is to set quantifiable goals. For instance, you can quantify the quality of your code based on the number of support tickets over time, or based on the number of defects injected by development. You might also want to pay attention to markers including defect rate, defect density, and inspection rate, and set in place tools to gather such metrics.

Unfortunately, not many teams take advantage of such tools. Our developers at RubyGarage check review effectiveness manually, by writing down critical defects noted during review and then discussing them if necessary.

Effective Code Review Starts with a Solid Workflow

These tips should help you optimize your code review process. And your workflow determines how you manage code versions, where you upload new chunks of code, how you review that code, and so on. At RubyGarage we use Git, and these rules are defined in something called Git Flow, which we’ll discuss more another time.