Code Reviews
It's been a couple of weeks since I last wrote, so it is time for a bit of an update.
Much of that time was spent getting ready for, attending, or decompressing from the Austin Game Developers conference. Owen did a great job of talking about our experience there, so rather than repeating his post I'll just suggest you go read it. Austin is always a good time (both the conference and the city), and this year was no exception. On getting back, we all heard that Austin is the site of a considerable H1N1 outbreak, but it has been almost a week and none of us has come down with the flu, so maybe we avoided that part of the venue.
The last six months have been some of the most productive that I can remember. It might be because we were finally at the point where we had to confront the problems that stood between us and multi-node head on. It might also be that management has been inexplicably preoccupied. At any rate, we have gotten a tremendous amount of work done. We are now getting ready to start integrating the various pieces that will lead to multi-node into the code trunk. Once that happens, we fully expect all hell to break loose, but we then get to try to figure out what is going on in the code and what tools we can build to let us see this more easily. It should be a lot of fun.
Part of the integration is a lot of code reviews. As I said in an earlier post, no code goes into the trunk without a through review (and generally more than one). When some code is ready for review, the author of the code will find another team member who is willing and able to review the code, and the review cycle begins. We generally announce when some code is being reviewed on the dev@games-darkstar.dev.java.net mailing list, but thus far the actual review has occurred in private mail between the person whose code is being reviewed and the person who is doing the review.
Given the amount of code that needs to be reviewed, we have decided to change this process a bit. First of all, instead of finding a particular code reviewer, when the author of some code thinks that it is time for a review, the author will post to the mailing list looking for some reviewers. We expect that most of the reviews (especially at first) will still be done by members of the core team, but if there are interested members of the community, they are more than welcome to take a look as well (more eyes catch more problems). We also plan on posting the comments to the mailing list, so everyone can see what the comments are and how the author responds. This will not only let everyone who wants to follow a review get a better idea of what the code is about, but will let those outside of the core team get an idea of what the reviews are like.
For those who aren't on the dev mailing list, we will also be posting announcements of particular code reviews to the forums. There will be a posting to say that a review has started, and we will also try to do a posting at the end saying what the result of the review was. Again, the hope is that this will let a wider audience see what goes on with the reviews, as well as allowing those who are interested to see more of the review itself.
All of this is to say that you can expect to see more traffic on the dev list in the near future, and traffic that is different from what you have seen in the past. And it is also an invitation to any of you in the community to lend a hand when it comes time to do the reviews.
Thanks for another great blog entry.
I would be interested in hearing more details about the mechanics of a code review on your project. For instance, if I have some code to be reviewed how do I make available to a potential reviewer? Is it on a branch off the trunk of the source code tree? Do I e-mail a set of diffs to my identified reviewer? After the review is complete and approved, do I then check it in or does the reviewer?
I am in search of what people consider the most optimal and effective way around code review procedures.
Posted by Thomas J. Kincaid on October 16, 2009 at 03:11 PM PDT #
The link for the blog about Austin doesn't seem to work...
Posted by Tim B on October 18, 2009 at 06:45 AM PDT #
Arrrgh... fixed now
Posted by Jim Waldo on October 18, 2009 at 09:14 AM PDT #