What To Focus on During a Code Review

by | Jan 23, 2019

To many, code reviews are just a waste of everyone’s time or can devolve into a petty gripe session between colleagues with an ax to grind. However, I have learned that a thoughtful code review can be one of the most important parts of the development process.

 

Code Review Strategies

Here are the things that I focus on when participating in code reviews:

  1. Do the changes being reviewed target and solve the core issue?
    The first thing I do is look at the requirement being met by the change and make sure that the changed code is truly solving that core requirement and not (in the case of a bug fix) just fixing the symptoms.
  2. Does the change meet the requirements everywhere it should?
    Can we learn from the need for this change and apply it elsewhere? For example, are there similar business rules or calculations that need to be updated in another part of the code?
  3. Has the change been done in the proper place?
    Well-organized code is important from a maintenance perspective so I always look to see if the change was implemented in the proper place.  Should it be broken out into a new service or class? Can it be grouped with related code?
  4. Is the change as simple as it can be?
    Clever is good but simple is better, and as I’ve learned many times from people who have reviewed my code, the change you’ve just completed can probably be done in a less complex way if you take a step back and look at it again.
  5. Is the change as efficient as possible?
    From a resource perspective, have you made the change as performant and resource efficient as it can be?
  6. Has the change been documented properly?
    Now that the change is complete, has it been documented in a way that another team member can understand it?
  7. Does this change require any tests to be altered or written? 
    While I don’t tend to subscribe to strict code-coverage standards (like 90%) I do always make sure that new changes are covered by tests wherever it makes sense.
  8. Does the change conform to the team’s style and formatting standards?
    While these are not the first things I look for, I do agree that it is important to be consistent with your team in regards to formatting and style.
  9. Did I learn anything?
    Finally, I look within a bit and ask myself if I see anything in the change that I can learn from. I often find things that I incorporate into my own coding when reviewing someone else’s.