Over a million developers have joined DZone.

How You Should Think About Code Reviews

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. I’m going to give you a small tip that will change the way you approach code reviews.

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

Code reviews, Test-Driven Development, and Continuous Integration are considered must-haves in terms of ensuring code quality these days. Most companies already have processes in place just to make sure that developers are following these practices on a daily basis. When it comes to TDD or CI, rules are simple—you just need some practice and common understanding and you are ready to go. The correlation between time spent on improvements and resulting effects is clearly visible in the short and long run. So even if your process is not perfect, most probably you will benefit from it to some extent. Doing peer review is much harder simply because…

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.

Summary

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.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

Topics:
code review ,code review tips

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

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

{{ parent.tldr }}

{{ parent.urlSource.name }}