How To Properly Use Code Reviews

Code reviews can be either a fantastic tool to maintain a stronger codebase that is freer of bugs and issues, or it can be a stressful and anger filled hour where half your team plans to quit the next day. And as someone who has taken a part in both of these scenarios, the following are my best guidelines for how to properly run a code-review in which nobody quits or gets fired and which could, in fact, make your team a more cohesive unit.

source

Not every team or every company needs to have code reviews in place, however. For example, if you work solo on a project at work, which will happen many a time, and your project manager hasn't been around your seat in 2 months, it's fair to say that having a code-review might not benefit you. If you are working on a complex project however with a small team, or if you are a younger programmer who still feels nervous checking in code, then code reviews are a great way to both learn and to share knowledge.

They can gauge your teams skillset

Knowing who can do what on your team is incredibly important for saving time on projects and for reducing bugs. You're never going to have a team where each individual is a 1 to 1 match with the other. Even with the same number of years of experience, people's ability to work usually comes down to many more factors than just skill set. Some people code more hours outside of work and so they tend to encounter more situations, while others are much better at implementing 3rd party libraries in a short amount of time. Two, very useful, traits. But this is particularly useful for younger developers who probably think they are amazing. At one time in my early years, I equally thought myself the senior engineer. Until production databases were deleted and memory leaks ran rampant. These are things that are normally not taught in a college environment after all.

This isn't a time to blame or to find fault. But to see if anybody struggled with building anything. To realize that maybe your mid-level developer really doesn't have too much experience with server security exploits. And how you can begin to alleviate that problem. This is a major reason why many would prefer to avoid code-reviews in general, as they don't feel too confident with their skillset.

They reduce the ownership of the project

If 5 people on your team each have their own coding standards, then it's going to get messy pretty fast. You're going to end up with inlined styles mixed with strangely named CSS classes and uneven capitalization all over the place. So even before the code review, having proper coding standards in place will help in the long run.

The following is very common, and while not a huge deal, it does tend to confuse and will cause needless sighs and updates later on when the codebase grows to a larger size.

var intNumberOfHours = 0;
var numHours = 0;
var hours = 0;

None of these are wrong from a technical standpoint. However, each person working on this team will probably end up changing the 2 lines that do not match their standards. Code reviews help in this scenario because they tend to remove ownership of the code in a general sense. With your code at home feel free to update in any way that you wish, however, with this work-code you'll have to remember that you are not alone.

They keep everyone in the loop

And more importantly, they keep everyone in the loop on what everyone else is working on. You'll get to see that you're a part of a team, and while you may be sitting alone coding in your cubicle, you're also helping the guy that sits across from you in getting his module up and running. Programming, for the most part, is a one-man job usually, so these little get-togethers every so often are also a nice way to unwind from typing. Having to work on some projects can be daunting if you're alone. But if you're a part of a team, then stress is shared evenly.

one can go fast, but the many can go far...

Just knowing that you aren't 100% alone in your project can be enough to keep you going through the more difficult parts. One of the most common issues that will be faced on complex systems are logic errors. And not accidental errors, but just errors based on misinformation. One person heard this in a meeting, and the other heard something completely different. This happens all the time and is probably the major source of bugs and errors and exploits that you will find on any website.

So more so than just looking at the code, this is a good time to actually discuss the project at hand.

What code reviews are not

And lastly, but also important, you should not use code reviews to tell people how to code. This is a sure fire way to create more separation than cohesiveness and it happens more often than not. Many people think that the intention is to get "cleaner" code written by everyone, but that's too subjective. If you were to get "cleaner" code, you would probably just be listening to that one person who is specifying what "clean" means. We all have our opinions on why brackets should go here instead of there, but they are just opinions, and unless used for standardization, those opinions should be kept to a minimum.

So avoid criticism and focus on teamwork and helping each other out. Some of the most fun moments that I've had at past jobs have been during small meetings with the team discussing logic or helping each other solve difficult problems late into the night. After a good solid code review, no person should want to quit their job.