The Pragmatic Craftsman         :: Simplicity from complexity :: | About Me |

I hesitated posting this... The last thing I want is more red tape. However, after reading about code reviews in several sources, I am convinced that the reward is worth the price. The bottom line, code reviews improve code quality. While no silver bullet, they force us to write better code -- knowing that somebody else will evaluate it makes us do it.

I have never been part of a company where code reviews worked effectively, but at the same time, if implemented properly into the development process, they have the potential to improve the quality code in a significant way.

What's more, they enable cross-training programmers, mentoring, and enforcement of code conventions. Code reviews allow us to make sure that new people are "adopting" to "our" way of doing things, if there are any. They're the extra guard to protect the most-valued property: code.

A lot of the prominent IT gurus, like Grady Booch, Jerry Weinberg, Cedric Otaku (those are sitting on top of my mind now), are big proponents of code reivews. I believe Weigers even wrote a book on the subject.

What prompted me to write this is an excellent blog entry by Cedric Beaust, Why Code Reviews Are Good For You, http://beust.com/weblog/archives/000393.html. He explains why it's good and the different types of reviews. The following sums it up nicely:

"I strongly believe that projects that work without any peer review will end up with code of significantly worse quality, regardless of how talented or experienced the developers are. It doesn't matter how good you are, you can't produce top quality code all the time. We all get sloppy at time, and code reviews are here to address these times."

I think we should consider implementing non-blocking code reviews. Let's be honest, we all check in code that is sometimes sloppy, we could all use a little incentive to do better, and a lot of times we write code that only we can understand. Code reviews would be an improvement in this area.

How do we implement it? Good question. I believe that there should be some communication system in place. But the bottom line, each line of code should be looked at by somebody else and suggestions how to make it better should be requested of each reviewer (no heart feelings).

At my current job we have JIRA and SVN integrated, doing code reviews would be simple. Every SVN check in has to have a ticket ID. Before a ticket can be closed and the project released, every change has to be reviewed by somebody else and commented on. Before it can be closed, the reviewer would have to approve that the changes have actually been implemented.

We all strive to write good quality code whether we do code reviews or not, but it does not always happen. Knowing that our code would be reviewed would force us to do it every time.

Reference
Why Code Reviews Are Good For You, Cedric Otaku

Related
Code Reviews, very good java.net article

How to adopt XP? Here's how, from Extreme Programming Explained.

1. Pick your worst problem.
2. Solve it the XP way.
3. When it's no longer your worst problem, repeat.

I think the above is not only for adopting XP, but a good way to solve any development process issue. It is a good way to improve your process.

Here's how I think you can solve any process issue (a modified version of the above):

1. Start with your worst problem.


2. Try to continously solve it. Don't try to solve anything else; keep working on the individual problem until you see improvement.


3. Once you made it better, repeat.

Where else can this be applicable? I think this is also a good way to work on your individual problems.

You are not going to fix anything right away, start making small, step-by-step changes and you will get there sooner than you think.

Related
Good XP Practices, my recent entry

Extreme Programming has been around for years now. From what I hear, it has been successful. I like the process, but I don't think I could withstand all of the practices on a continual basis. Having to pair program on a continual basis is just a pain (bathroom, personal calls, taking breaks, etc). I think it could be done at times, for instance, fixing a critical issue, but on a day to day basis, I dont' think I would be able to do it.

Here are the practices of XP, taken from Extreme Programming Explained book, which I'm currently reading.

• The Planning Game -- Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.


• Small releases -- Put a simple system into production quickly, then release new versions on a very short cycle.


• Metaphor -- Guide all development with a simple shared story of how the whole system works.


• Simple design -- The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.


• Testing -- Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.


• Refactoring -- Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.


• Pair programming -- All production code is written with two programmers at one machine.


• Collective ownership -- Anyone can change any code anywhere in the system at any time.


• Continuous integration -- Integrate and build the system many times a day, every time a task is completed.


• 40 hour week -- Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.


• On-site customer -- Include a real, live user on the team, available full-time to answer questions.


• Coding standards -- Programmers write all code in accordance with rules emphasizing communication through the code.

Based on these practices, I think a good agile process should have the following practices (from the XP process).

• Small releases. A small release lets you find problems quickly and correct them right away.


• Simple design. There is no point on spending too much time designing for the future; nonetheless, some time should be spent on creating a good design, as a bad one can kill or seriously slow down development. No you cannot really refactor a bad design, you would have to rewrite it.


• Testing and Refactoring. We all say we do it, but I think we should be doing more of it. This is essential.


• Continuous integration. It's critical, as a lot of problems are exposed by integrating.


• 40-hour week. This is very important. I don't know about you, but I'm tired after work. I noticed that when I stay overtime from time to time, I enbug the system. Really. I put a lot more bugs into the system than normal. Plus, programmers have a life (we do).

All in all, XP brought a lot of good practices to the development world. It was, and still is, a disruptive force. And that's a good thing. Whatever your process is, make sure it is agile, and exposes problems early.