Skip to content

Comparing barkeep to other code review tools

philc edited this page Jun 28, 2012 · 11 revisions

We originally built Barkeep because after using each of the popular code review systems (Reitveld, Github enterprise, Phabricator and Gerrit) for a few months each, we concluded that none fit our needs well.

Every system has its weaknesses, including Barkeep. We think these are its strengths relative to other code review systems we've used:

Naturally supports post-commit workflows

Barkeep was built at Ooyala, where we usually prefer a post-commit code review workflow for our products. This is where developers push to master as soon as their code is ready (i.e. looks nice, tests are written and pass) so other developers can begin integrating it. Code review happens when it's convenient for the team (within 1-2 days), and any comments are addressed in future commits. We like this workflow because it's aggressively fast and requires low overhead. Barkeep is built for this.

Clean interface

A lot of time is spent reading and reviewing code, so the code review system should be easy on the eyes. Barkeep was designed with a minimal UI. The common actions, like leaving a quick comment adn approving a commit, are low-friction. And there's tons of keyboard shortcuts because the mouse is the devil.

A clean UI also applies to email. A lot of work went into making the emails Barkeep sends noise-free, useful and threadable.

Hackable

Last, we're coming up with workflow improvements all the time, and we build tools like continuous integration on top of our code review workflow, so we wanted Barkeep codebase to be small approachable, and easy to hack on.

Clone this wiki locally