Live data from Hacker News

Code reviews at Google

thebogles.com

1–10 of 18 posts

Re: Code reviews at Google

#2
http://www.fogcreek.com/kiln/ has almost all the features mentioned and they are really really useful. Free for up to two users with the students and startup discount. The free link takes a bit of digging to find if I remember correctly.

edit:

kiln: http://www.fogcreek.com/Kiln/StudentAndStartup.html

Better yet sign up for fogbugz and add kiln on to fogbugz:

http://www.fogcreek.com/fogbugz/StudentAndStartup.html

Re: Code reviews at Google

#3
I've been using gerrit extensively lately. It's a great review system on top of git.

I work with people around the world on software -- including people I've never met who decide to contribute a change (which enters the same workflow as a project lead). It's just awesome.

Re: Code reviews at Google

#7
After my experience with code reviews at Google, I came to the conclusion that Mondrian had some definite deficiencies. On the other hand, later at Mozilla, we did code reviews without any real tool support at all. That was a lot worse. I wrote up some of my thoughts in a blog post which you can find at http://curtisb.posterous.com/what-should-mozilla-look-for-in....

Re: Code reviews at Google

#8
post #7

After my experience with code reviews at Google, I came to the conclusion that Mondrian had some definite deficiencies. On the other hand, later at Mozilla, we did code reviews without any real tool support at all. That was a lot worse. I wrote up some of my thoughts in a blog post which you can find at http://curtisb.posterous.com/what-should-mozilla-look-for-in... .

> Mondrian had some definite deficiencies

You mean like its approximately two 8s uptime? :P I do think you're spot on about how Mondrian encourages the nit-picking and doesn't do enough to encourage structural discussions. On the other hand, maybe those discussions should be had before there's any code to review. So . . . meh. Tough problem.

Re: Code reviews at Google

#9
post #7

After my experience with code reviews at Google, I came to the conclusion that Mondrian had some definite deficiencies. On the other hand, later at Mozilla, we did code reviews without any real tool support at all. That was a lot worse. I wrote up some of my thoughts in a blog post which you can find at http://curtisb.posterous.com/what-should-mozilla-look-for-in... .

> Mondrian had some definite deficiencies You mean like its approximately two 8s uptime? :P I do think you're spot on about how Mondrian encourages the nit-picking and doesn't do enough to encourage structural discussions. On the other hand, maybe those discussions should be had before there's any code to review. So . . . meh. Tough problem.

I've always found it hard to do something like a structural discussion without having written some code first. At Google I found that I could request an informal code review in email rather than using the formal request mechanism ("g4 mail"). I could even provide a changelist number so the reviewer could look at it in Mondrian. But by having used email I could frame things so the reviewer would look at the high-level picture. That usually seemed to work.

Re: Code reviews at Google

#10
post #7

After my experience with code reviews at Google, I came to the conclusion that Mondrian had some definite deficiencies. On the other hand, later at Mozilla, we did code reviews without any real tool support at all. That was a lot worse. I wrote up some of my thoughts in a blog post which you can find at http://curtisb.posterous.com/what-should-mozilla-look-for-in... .

> Mondrian had some definite deficiencies You mean like its approximately two 8s uptime? :P I do think you're spot on about how Mondrian encourages the nit-picking and doesn't do enough to encourage structural discussions. On the other hand, maybe those discussions should be had before there's any code to review. So . . . meh. Tough problem.

I found structural discussions took place in the free form areas of mondrian, and knit-picking was a direct result of two aspects: 1) An strict, but oft changed style guideline 2) The requirement to say something beyond LGTM to prove that the code review was thorough.

The one aspect I missed at Google compared to other large software companies was design document reviews. I found that in writing and disseminating such documents a lot of good work was done.

Post reply on HN