Bitbucket code review

Code reviews are an important part of the modern software development workflow – especially for those teams working in git repositories like Bitbucket, where you need a tighter pull request process to maintain the overall quality of your source code.

Get started

Thousands of companies - from startups to large enterprises - use Codacy. Every day.

Used by Autodesk.
Used by Paypal.
Used by Adobe.
Used by Schneider electric.
Used by O.C.Tanner.
Used by Blue Bottle Coffee.
Used by Delivery Hero.
Used by Toptal.
Used by Cancer Research UK.
Used by Deliveroo.

Codacy and Bitbucket

Codacy is a great choice for Bitbucket code review! It's easy to connect your Bitbucket repository with our integration, and once you're up and running you can review new pull requests, and push issues directly back into Bitbucket for collaboration with the pull request author and wider team. The Codacy dashboard also makes the Bitbucket 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.

Pull Request flow

For every new pull request made, it’s vital that your team is able to quickly (and accurately) spot problems and decide if new commits meet 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 Bitbucket account, or you're looking to improve your existing process, try following our simple rules and learn how to implement a great git code review process and workflow.

Code reviews play an important part in the development process, but can often be a source of frustration, so follow these simple rules

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.

Setup a process

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.

Use code review checklists

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.

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.

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.

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 strive to make the code review process easier through automated analysis, so your team can be more efficient, and improve code quality.

The ultimate guide to code reviews - Edition II

Setting up a proper code review workflow might seem like a complex task at first, but by addressing this process early on, you guarantee better results in the long-term. For a more detailed guide, with recommendation drawn from interviews with almost 700 developers, download our ebook.

Get this ebook