Better Code on a Budget and Training for Free

DZone 's Guide to

Better Code on a Budget and Training for Free

· Agile Zone ·
Free Resource
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.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}