Unfortunately, coming from Google he had some very neat tools to help do this that (as far as I know) don't have equivalent counterparts outside Google. It would be harder to do, but distributed version control could help considerably. One possibility would be to make everyone commit to their own local repos and then force a pull request every time they want to commit something to the main repo.
This is how Kiln[1] got started at Fog Creek. We wanted a good way to do code reviews after checking it in to a branch. (Checking in before you review makes it possible to review the changes in steps, instead of looking at one huge diff.) Django Dash was coming up, so we entered and made that our 48-hour project. By the end of the weekend we had a basic prototype that took two Mercurial repos (branch-by-clone) and calculated the diffs from that.
Fast forward a couple of months, Joel was talking about adding SVN to FogBugz. We were sick of SVN and had this prototype, so we polished it up, presented it, and got approval to start working on it for real.
I'm an advocate for code review at the current place...
We already use fogbugz, and I'm pushing for us to switch to hg from svn so that we can use kiln too. Code review is one of the main features that I'm using as a lever. I fear that status quo / apathy may prevail though, since there is a contingent that wants to use git and if it's not unanimous, we stay where we are. Sigh.
Btw, our current process is a skype channel that we use to post links to commits (we use trac at the moment). It actually works pretty well.
Oh, you likely still will have to give it up. You can tell people how well the system works, but the idea of having code review on every checkin sounds like such a heavy process that you'll never convince anyone else to do it.
When I wanted to submit some patches to one of the Protocol Buffers projects, I was asked to submit them via Guido Van Rossum's Rietveld tool, which is a public re-implementation of an internal Google code-review tool: http://codereview.appspot.com/
We do code reviews after the code hits the repository. Jira's Crucible tool is awesome for that (it is basically an extension of Fisheye, which is great in its own right). I could imagine Google managing code reviews with something like Crucible just fine, though I may underestimate the consequences of the organisational consequences of sheer size.
Everyone is responsible for making sure the code that hits the repo is up to scratch. Sure this means more bugs hit the repo, but reviews are not primarily about catching bugs: they are about code quality. There's always room for improvement that only other eyes catch, even when there aren't any bugs. The goal is to be bugless without code reviews and people shouldn't start trusting upon code reviews to catch their bugs.
Comments
Unfortunately, coming from Google he had some very neat tools to help do this that (as far as I know) don't have equivalent counterparts outside Google. It would be harder to do, but distributed version control could help considerably. One possibility would be to make everyone commit to their own local repos and then force a pull request every time they want to commit something to the main repo.
This is how Kiln[1] got started at Fog Creek. We wanted a good way to do code reviews after checking it in to a branch. (Checking in before you review makes it possible to review the changes in steps, instead of looking at one huge diff.) Django Dash was coming up, so we entered and made that our 48-hour project. By the end of the weekend we had a basic prototype that took two Mercurial repos (branch-by-clone) and calculated the diffs from that.
Fast forward a couple of months, Joel was talking about adding SVN to FogBugz. We were sick of SVN and had this prototype, so we polished it up, presented it, and got approval to start working on it for real.
[1] http://www.fogcreek.com/kiln/
I'm an advocate for code review at the current place...
We already use fogbugz, and I'm pushing for us to switch to hg from svn so that we can use kiln too. Code review is one of the main features that I'm using as a lever. I fear that status quo / apathy may prevail though, since there is a contingent that wants to use git and if it's not unanimous, we stay where we are. Sigh.
Btw, our current process is a skype channel that we use to post links to commits (we use trac at the moment). It actually works pretty well.
The key tool does have an equivalent counterpart, written by the same people who wrote Google's tool. See http://code.google.com/p/rietveld/ for more.
Perfect, I thought I was going to have to give up Mondrian if I left.
Oh, you likely still will have to give it up. You can tell people how well the system works, but the idea of having code review on every checkin sounds like such a heavy process that you'll never convince anyone else to do it.
Guess ill have to take some Googlers with me ;)
Gerrit is open source and is what's used on the Android team: http://code.google.com/p/gerrit/
When I wanted to submit some patches to one of the Protocol Buffers projects, I was asked to submit them via Guido Van Rossum's Rietveld tool, which is a public re-implementation of an internal Google code-review tool: http://codereview.appspot.com/
We do code reviews after the code hits the repository. Jira's Crucible tool is awesome for that (it is basically an extension of Fisheye, which is great in its own right). I could imagine Google managing code reviews with something like Crucible just fine, though I may underestimate the consequences of the organisational consequences of sheer size.
Everyone is responsible for making sure the code that hits the repo is up to scratch. Sure this means more bugs hit the repo, but reviews are not primarily about catching bugs: they are about code quality. There's always room for improvement that only other eyes catch, even when there aren't any bugs. The goal is to be bugless without code reviews and people shouldn't start trusting upon code reviews to catch their bugs.