Code Reviews: What I Look For
Published in
2 min readJul 7, 2018
Code reviews are part of the daily workflow of most engineers, and the team I work on is no exception. We have a two-person approval process for each pull request before merging any code, so the code review process is one we take seriously. Apart from that, it’s one of my favorite parts of software development: I get to expedite my learning by using someone else’s code as cliff notes!
We had a major release this past week that made me start thinking about standardizing my code review process, making sure I cover my bases when rushing towards a major deadline.
Below are the main things I look for during code reviews, hope it helps you and your team:
- Does this handle nil values? Can a nil value show up anywhere here, and if so, how is it handled?
- Is this syntax clear and easy to follow? Can we simplify any unnecessarily cunning code?
- Does this logic belong here, or should this functionality be defined somewhere else?
- Should this piece of code be tested? (Referring to little helper methods that aren’t part of what’s commonly tested.)
- Can this be re-used somewhere else? If so, should we extract it into it’s own standalone thing?
- Is this implementation consistent with how we do things across our application?
- How would I solve this, and can anything from my approach add value here?
- Does this break existing functionality?
- Is this algorithm efficient or is there a better way to write this?
Feel free to comment the things you find valuable to look for as well!
