Code Critiques
–
Tuesday, Jun 26, 2007 / 5:56pm View more articles
Every Tuesday afternoon the developers at iMarc hold group meetings. We talk about such nerdily interesting topics as code standards, ways of indenting CSS, naming directories, frameworks, and any other programming issue that we deem worthy.
About six months ago we started holding code critiques. They've been really positive and educational. Here's what we do...
1. On Monday – sometime before lunch – one or two developers post a single page of their code on our Wiki. Maybe it's a snippet from a class, maybe it's part of a page, maybe it's a complete small class. We try to keep the code posting somewhere under 300 lines.
2. All the other developers download and review the code.
3. On Tuesday afternoon, during our weekly developer meeting, we look at, talk about, and critique the code snippets.
The intent is not for the developer to write of the perfect 300 lines of code or spend 4 hours finding the cleverest ternary condition they've ever written. Instead, they just pick anything that they want to get feedback on.
For those critiquing the code, they offer constructive criticism. If you're the person doing the critique, you also often find yourself thinking, "wow, that's a really neat way of doing that...."
Whether your getting critiqued or doing the critiquing, you tend to learn something with every review.
The idea sprang from design and photo critiques that I had to do in college. These typically included getting an assignment one week, then doing the assignment, hanging it on the wall, and letting the class rip into it the following week.
Our code critiques have been really helpful and constructive. If you work with two or more developers, I highly recommend trying code critiques.
About six months ago we started holding code critiques. They've been really positive and educational. Here's what we do...
1. On Monday – sometime before lunch – one or two developers post a single page of their code on our Wiki. Maybe it's a snippet from a class, maybe it's part of a page, maybe it's a complete small class. We try to keep the code posting somewhere under 300 lines.
2. All the other developers download and review the code.
3. On Tuesday afternoon, during our weekly developer meeting, we look at, talk about, and critique the code snippets.
The intent is not for the developer to write of the perfect 300 lines of code or spend 4 hours finding the cleverest ternary condition they've ever written. Instead, they just pick anything that they want to get feedback on.
For those critiquing the code, they offer constructive criticism. If you're the person doing the critique, you also often find yourself thinking, "wow, that's a really neat way of doing that...."
Whether your getting critiqued or doing the critiquing, you tend to learn something with every review.
The idea sprang from design and photo critiques that I had to do in college. These typically included getting an assignment one week, then doing the assignment, hanging it on the wall, and letting the class rip into it the following week.
Our code critiques have been really helpful and constructive. If you work with two or more developers, I highly recommend trying code critiques.
Comments
Tuesday, Jun 26, 2007 / 9:45pm
∞
Code review and pair programming can also have those effects, but this is a neat idea.
Wednesday, Jun 27, 2007 / 9:30am
∞
I agree with PJ. In my mind, the real reason for Extreme Programming's collective code ownership and pair programming is to push this kind of collective review straight into the code-writing phase.
I believe that the effectiveness of both approaches comes from having multiple people look at each other code thus improving at once the code quality _and_ the skills of the developers.
Comments have been turned off on this blog.
Read something more recent.
Read something more recent.
Statements and opinions expressed in this blog and any comments made are the private opinions of the respective poster, and, as such, iMarc LLC is neither responsible nor liable for such content.
Visitors
If this practice was a Virus, I would secretly hope it was a good one and everyone would catch it. Too many times I've had to debunk code because someone JCP'd it (Just Copy Paste) without understanding what it was doing and it went from functional to borked. We've been doing this lately too in our Dev meetings as a way of really digging into the code and utilizing all of our team assets to complete to goal as best as possible. We have a bunch of different "experts" in various coding languages and getting the chance to all sit down and tear apart some code has been an extremely beneficial practice, more than a mean exercise is making someone look stupid.