I'll add one more: as you go along, document a summary of any non-trivial discussions from the code review, in the code itself.
If the reviewer and the coder needed to talk over some aspect of the implementation at length, it's a safe bet future readers of the code will benefit from it too.
At UIUC, we have a class called "Programming Studio." Each week there's a different assignment, and every three weeks or so the class switches languages. In addition to making our chops better, a focus of the class is communication.
At the beginning of the semester, we were split into discussion sections of 6 students each and a moderator (grad student or a past student who was very good). Now, once a week, we have 2 hour sections where we look at each persons code and are graded on conventions, design decisions, and, perhaps most importantly, the ability to critique our own and others' code.
I guess I kind of took for granted the usefulness of this experience. Perhaps I'll try to look forward to it a little more each week ;)
I think this should be required reading for anyone doing code review. The big problem I see with code review is that people treat it with the same broken beliefs as with things like unit tests. That is, they assume that any code review is better than no code review, which isn't true. In fact, it's incredibly easy to get code review wrong. I certainly can't claim to always get these things right.
The first two points are very non conventionl and very important. Typically a code review is where you get feedback on how the code has been written from the experts in the area. But he reverse is also very true. As a new developer reviewing an expert developers code can be very good learning experience.
Definitely this. It can be helpful to both parties. The learning opportunities for experienced developers start to thin with time, and one of the best ways to combat that is to get a fresh perspective.
In my experience, even if you're not learning any new concepts or techniques, you're learning about parts of the code base you would maybe not touch normally. This can be a huge advantage when it comes to localising/fixing bugs later, or when the "owner" of some code is on holiday (or sick, or has left the company) and urgent changes need to be made in "their" code. Having at least 2 people know about every corner of the project is worth the cost of the code reviews.
8 comments
[ 5.2 ms ] story [ 23.6 ms ] threadIf the reviewer and the coder needed to talk over some aspect of the implementation at length, it's a safe bet future readers of the code will benefit from it too.
At the beginning of the semester, we were split into discussion sections of 6 students each and a moderator (grad student or a past student who was very good). Now, once a week, we have 2 hour sections where we look at each persons code and are graded on conventions, design decisions, and, perhaps most importantly, the ability to critique our own and others' code.
I guess I kind of took for granted the usefulness of this experience. Perhaps I'll try to look forward to it a little more each week ;)
I doubt it can be done without rubbing a few people the wrong way (at which point it properly needs to be used as the exemption, not the rule).