4 Steps to doing code reviews for the uninitiated.

There was a time when code reviews were reserved for the senior coders or the grand wizard architects of teams so that they could “maintain the quality of the code base”. Thankfully we’ve shifted from that and we now utilize code reviews for its other benefits like knowledge and information sharing, increasing collaboration and preventing any bugs or unwanted behavior from getting out into the wild.

This shift though has brought about some other problems, we now have people who have to do code reviews but they don’t really know where to start or what to do. Well, I’m here to help. Here are 4 steps to doing code reviews for the uninitiated.

1. Read the specifications

This is the first thing you always have to do. No exceptions to this one. While code reviews focus on the code that’s been written, you first have to know “why” we wrote that code, to begin with.

Reading the specifications also gives you the chance to come up with error scenarios that you expect the code should be able to handle.

2. Run those automated tests

If you’re working on a project with automated tests then this step is crucial. Look at all the tests that were added for this change, does it cover a good deal of the possible scenarios that can happen? What about all the other tests did they break?

For most people, these automated tests would be their unit tests which if written well should be quick and easy to run. Making sure all tests are green before moving forward would be a good step.

3. See the output for yourself

There has to be a way to see what the results of the change are. Whether its a new page on the site or change in logic somewhere you have to see it for yourself. Even database scripts can be run on a sandbox to see if it does what it’s supposed to do.

4. Look for the common errors

Now that you know it works and the automated tests pass its time to actually look at the code. While there are many things that you could look out for these are the pretty common offenders

  1. Not following code standards (ie: variable naming, tab spacing, commit comments, code comments, etc.)
  2. Null & empty string handling. For things that could be null or empty, check if the rest of the code handles it gracefully.
  3. Repeated code and other refactoring opportunities.
  4. Non-existent error handling and logging. Depending on your project’s standards this may or may not be a big thing. Personally, I like being able to catch exceptions, log them and show a friendly message to the user.
  5. Freeing up resources. Check for things like database connections or memory streams. See that they’re being disposed of properly.

There they are! My four tips to doing code reviews for the uninitiated. Hopefully, these give you a good base to start developing your own code review style and technique.

 

Leave a Reply

Your email address will not be published. Required fields are marked *