Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans

Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Better Code on a Budget and Training for Free

04.28.2010
| 9995 views |
  • submit to reddit
There are many ways to improve your code. Some are cheap, others expensive. There are tools, processes, conferences, and metrics. There are so many different ways that we're told how to write better code. We're told in books, at conferences, in classes, and even on web sites like DZone.

But the single best way I've found to write better code is fairly easy and inexpensive. There's an old saying in the open source community... "Given enough eyes, all bugs are shallow" http://en.wikipedia.org/wiki/Linus'_Law

Since most of us can't upload our code to the internet and get thousands of different people to look over it, what else can we do to make our bugs shallow? Get at least a second set of eyes on your code.

Will Gwaltney and I first wrote about peer code reviews a few years ago in Ship It! A Practical Guide to Successful Software Projects and I still find it an incredibly useful tool.

Peer code reviews are very easy to use. Simply put, explain your code to a coworker before you check it in. This isn't a large or complicated process. Instead, after you finish one feature (or fix one bug), go find a teammate who's not deep (in code, in thought, etc), and walk them through your work. By explaining your work to another person, you'll spot many of your own problems, and you're giving another skilled professional a chance to offer feedback.

There are a few guidelines.

First, only get a few days worth of work reviewed at a time. If you hold onto your work for a month or two, the review would be huge and painful. Instead get a review every few days. (For ideas on how to limit your work to smaller features, read my recent article on 3x5 Cards http://agile.dzone.com/articles/3x5-cards-what-waste )

Second, explain your code line-by-line, and when someone asks a question, fix the problem. The problem is that the question had to be asked. "What does this variable hold" means you need a more meaningful variable name. "What does this block of code do?" is crying out for a subroutine.

Third, never interrupt someone for a review. Ask if they have time for a review, and take "No" for an answer. Don't ask for a time you can return, just move on. Letting code reviews drive constant interruptions is a horrible abuse of the idea.

Lastly, get this review before you check in your code. I've found that developers are much more likely to change "small" things before they've checked in their code. After it's in source code management, it seems like a big deal to change a variable name. Before? Not so much.

Peer code reviews will help find bugs, give others insight into your ideas, and let others give you their ideas. It's a great way to share lessons learned, new technologies, and break down knowledge silos. The next time you write some code, get someone to review it with you. It's the cheapest bug removal system you'll ever find.
Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Bino B. Manjasseril replied on Thu, 2010/04/29 - 6:24pm

Great post! I am all for peer code review, but I find it little disappointing when most people in the team look at it as an extra burden. I suggested code review as a team to my boss (using a projector and 2 or 3 people looking at the same code), but I failed to convince the idea. I love it when other people critique my code. But unfortunately not all all developers are as open as I am :) How do we sell this idea in a non-threatening fashion?

Jared Richardson replied on Sat, 2010/05/01 - 12:06pm in response to: Bino B. Manjasseril

I love one-on-one peer code reviews, but I'm not a big fan of group reviews. It can be of benefit if done from time to time, but there's a real overhead to the pulling everyone "off the line" and putting them in a room to look over your code. That cost might be what your manager is considering, not the benefits.

Ben Franklin said if you want to make a friend, ask a favor, and that's my advice to you. If you want to get a second set of eyes on your latest bit of code, print it out and go find someone who's not deep in work, and ask them for a favor. Ask them for a review. Tell them the problem was tricky, or you want to make sure it's right, or just tell them you'd like to get a second opinion on your solution and your code.

Find a coworker, and ask a favor. If you do this for a few weeks, you'll have broken down many of the barriers to the reviews. I usually find others start asking me to review their work as well. This type of practice can become a de factor standard without any formal declarations.

Just remember to keep them small and fast. This minimizes the perceived cost to management and minimizes your intrusion to your coworker's day.

Let me leave you with words of Gandi. Be the change you want to see in the world. If you think peer code reviews are a good idea, don't try to talk everyone else into doing them. Start doing them yourself.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.