Code Review Takes a Lot of Time!
And since time is the most scarce resource that we have nowadays—especially in the IT world where every project is behind schedule before it even begins—we tend to cut corners. So instead of doing great peer reviews, programmers quickly go through code just to verify that code conventions are met, tests are passing, and no obvious bugs are present without focusing too much on the design itself. As an effect companies don't achieve the amazing ‘X reasons to do peer review’ that can be Googled easily. At least that's what I've seen for the past few years…
I’m not going to tell you how to do amazing, mind-blowing code review because there is more than one way of doing so and you have to find your own way. Instead, I’m going to give you a small tip that will change the way you approach code reviews in the future simply because...
Code Review Is Like Hacking Someone Else’s Idea
This is how we think of it in Pragmatic Coders and here's why… Mistakes that are easy to spot, are equally easy to repair. One man in one day can do an enormous amount of renames, method extractions, style improvements and bug fixes provided that he has the right tools and attitude. What one man can’t do is re-arrange the architecture of your system, fix performance issues that were introduced by some reckless design, reduce inconsistency in data on a live production system just because it can’t be stopped for a few hours in order to rename the table or column. Naturally I'm not saying that you should cross out simple checks from your reviewer’s list, but small shifts in thinking can really make a great difference. Understanding why the change was made in the first place, what possibly can go wrong, what is the strongest and weakest point of a new design, or how you can extend it in the future, are the keys to successful maintenance and development of a relatively complex system.
The best reviewers that I have met in my life were always focused on long-term benefits and overall design consistency more than on tiny, clean code “quirks,” and this is exactly an example that we all should follow to make our products even better.