I wrote in 2008 about Review Board, a code review package I’d tried and liked. Unfortunately our developers didn’t like it as much as I did, and having learned my lesson (thanks, FogBugz), I declined to impose a tool choice on them. They chose Gerrit, instead, which is more tightly bound to Git, and has some nice features related to that (such as pushing to master from a button in the UI when the review is complete). The rest of the UI is very unpolished, but has been getting progressively better.
Code review caused some frustrations for us — the immediacy of “code, check in, ship” was lost, and it took some time for us to get to a new running pace. The benefits, though, were very obvious: we had dramatically fewer periods of downtime or instability after introducing reviews, and the overall quality and consistency of the code went up a lot. The mutual obligations created by asking for reviews changed the social dynamic for the better. Peer pressure caused people to report that they were much more hesitant to check something in with poor test coverage or an embarrassing hack. While anything that slows the pace of development kills me, the net payoff was high. (See Cedric Beust’s 2006 post, “Why code reviews are good for you,” for a great discussion of code review models and tradeoffs.)
When looking for a tool we also considered GitHub:FI, the “behind the firewall” version of GitHub. It wasn’t really up to par when compared with Review Board, Crucible, or Gerrit. But so many things about GitHub are so appealing that we all wanted it to work. That’s why I was excited to see today’s announcement from GitHub, “Introducing GitHub Compare View” — especially this note at the bottom of the post:
Compare View is the first of many code review related features we plan to introduce this year. We’ll be incorporating Compare View into other areas of the site and developing entirely new features with Compare View as a core component.
Great. That’s awesome. Can’t wait to see what’s coming.