Github Code Review

Code reviews are an important component of the modern software development workflow – especially for those teams working in Github, where you need to maintain the overall quality of your source code and ensure updates aren’t going to compromise the integrity of your product.  


START A FREE TRIAL

Copyright © Codacy. All rights Reserved.

Why code review?

THOUSANDS OF COMPANIES USE CODACY TO ANALYSE BILLIONS OF LINES OF CODE. EVERY DAY.

Start shipping quality code today

SIGN UP WITH BITBUCKETSIGN UP WITH GITHUBSIGN UP WITH GOOGLE

By clicking "Sign up" I agree to Codacy's Terms of Service .

Ok, so you know that code reviews are critical to preventing problems from entering your production environments. But did you know that teams that implement a great code review process also deliver improved code quality, and ship code faster?

And with release cycles now measured in days (and even hours), a slick code review process is one of the most effective changes you can make!

2. Setup a process

4. Work with team members

Errors can easily slip through if you work by yourself. By implementing peer code reviews in your development process, you ensure that more than one pair of eyes analyses the code. By doing this, you'll benefit from more effective code reviews, and find new solutions that could have easily been missed if only seen by a single developer.

You might also want to look at letting all of your developers review code from time to time. It brings a sense of ownership and is a great way to spread knowledge across junior team members. On average, developers should spend between 0.5 - 1 day per week reviewing code.

5. Reporting and fixing bugs

Code reviewing isn't just about the review. The way you report and fix bugs is just as important. That's why you'll need a well structured reporting and fixing process. 

For reporting bugs, it's vital to establish what information is important for the programmers. It's also important to define who will be responsible for analysing and prioritising those bugs so you can reduce confusion and wasted effort.

When looking at fixing bugs, you should be clear at what stage of the process the bugs will be addressed and how they might affect pull requests.

6. Choose the right tools

Even if you had all of your programmers reviewing your source code, mistakes will undoubtedly slip through! Unfortunately, the traditional code review processes can be laborious and time consuming. Some teams might even avoid running code reviews purely because of the perceived time wasted, versus the benefits gained.

Code review tools such as Codacy offer new ways to maintain code quality standards and strive to make the code review process easier through automated code review analysis; so your team can be more efficient, deliver better code, and improve code quality across your organisation.

One of the biggest pitfalls is not establishing a documented code review process. This means that team members don't understand where, when, or why they should review code. Without it, teams can even be mistaken into thinking that the process is actually counter productive, rather than beneficial.

Establish a process that works best for the size of your team, their needs, and level of communication. Establish owners of the code review process, who will conduct the reviews, and who will benefit most from the code reviews.

To help you set-up your own process, try the OWASP Code Review Guide Table.

Even the high-level developers on your team can make mistakes when reviewing the code base. The best way to reduce the probability of errors is to use a checklist that takes into consideration the standards and quality that have been established for your product. We've found that teams that have a quality standards checklist actually spend less time fixing bugs and more time building new features

It is also a great way to keep control of what's been done, and what still needs to be reviewed.

1. Review early. Review often

Many organisations run their code reviews at the end of the development process. This might seem logical, but it's not actually the most efficient approach. Having worked with hundreds of development teams around the world, we've found that the teams that run code reviews before deployment, actually spend the least amount of time fixing bugs and making code changes. That's because, by running code reviews earlier in the process, teams are able to improve productivity by identifying issues before programmers waste time building more code on top of already broken code.

So, by reviewing early, and reviewing often, you can reduce code changes and simplify developer peer reviews.

Codacy and Github

Codacy is a great choice for Github code review! Not only does our integration allow you to manage each and every pull request, and push issues directly back into Github for team collaboration with a single click, but the Codacy dashboard makes the Github review process more meaningful by giving you a complete overview where you can measure the quality impact of each and every pull request on your code base.

You can sign up for Codacy with your Github account or visit us at the marketplace on github.com. It's free to use for open source projects!

Whether it’s a new feature, a modification, or a bug fix, for every Github pull request made, it’s vital that your team is able to quickly (and accurately) spot problems, and also decide if the request meets the code quality standards set by the team.

That’s why, before an open pull request is merged, your team should be following a well-documented code review process, and have visibility of how requests have impacted the overall quality of your source code.

Whether you’ve only just signed-up for a GitHub account, or you're looking to improve your existing process, try following our simple rules for implementing a great git code review process and workflow.