Over the years, I've had the opportunity to work with many junior developers on my teams. A valuable activity they are often hesitant to get involved with is reviewing others’ code. It can be especially intimidating when that code is coming from a very senior member of the team.
I have always encouraged those developers to review code regardless. You don't need to be a senior member of the team to get involved. Reviewing code is a useful skill and can teach you a lot, such as:
It helps you see how other developers approach different problems.
You can frequently see neat language and tooling features that you may be unaware of.
It keeps you up to date on the changes happening in the code base.
Read on for a list of tips to make reviewing code more approachable even if you are the most junior member of the team.
Read up on the context of the change
Before looking at any of the code, it can pay off to read any available external sources on the change. These sources should provide important information about why the change is being made. There are a variety of places you may find this information including:
Ticketing systems (e.g. Jira, Linear, Github Issue)
Bug reports
Design documents
Be sure to read through the Pull Request description or commit messages, as these provide a written history of the code. If they are difficult to understand, it might be worth asking the author to improve their clarity.
Categorize the change
There are a few categories that changes fall into. Understanding the category a change belongs to will help you focus your attention.
Some common categories you will run across are:
New features
Bug fixes
Refactors
I expect bug fixes to be small and targeted. If I came across what I thought was a bug fix that changed a lot of code, I would be a bit concerned. It might be that the author is combining a bug fix with a refactoring. This might be worth discussing in the review. Break up your review: split the review into a review with the refactoring and a review with the bug fix. The two more targeted reviews would be easier to consume both when reviewing the code and when reading the history.
Don't worry about styling or formatting
It can be easy to make a lot of comments about styling and formatting issues but these tend to not be very useful and can come across as nitpicking. Consider investing in linters and formatters if you feel like there are a lot of real issues in these areas. Machines are more reliable and consistent in enforcing these rules, this allows you to focus your energy on the behavior of the actual change.
Approach the review with curiosity
Don't worry about finding every possible bug that a change could cause. Instead, try to learn something from the change. Are there parts of the code you don't understand? Ask about them. Are there language features the author is using that you are unfamiliar with? Read up on them.
Don't view yourself as a gatekeeper of the code, be curious about the change and see what you can learn from it.
Understand the change
Be sure to understand the code change and avoid falling into the trap of just rubberstamping a change. If the change is a bug fix: how does the change fix the bug? If it is a new feature: how does this new feature behave?
If you don't understand how the change works, ask about it.
Ask the author for a walkthrough
If you are struggling to understand a change, ask the author to sit down with you in person and walk through it. Most people would be more than happy to explain their changes to you. In fact, many more people enjoy showing their work to interested parties.
Have the author explain the context of their change and the surrounding code. This can be an excellent opportunity to grow your knowledge of the surrounding code as well.
Checkout the code and interact with it
A great way to understand a code change is to actually run it; checkout the code on your local machine and experiment with it.
Try running the code with and without the proposed change. Can you recreate the behavior the change is meant to address?
Step through the changed code in a debugger. See how the change impacts the variables and data in real-time.
Run the tests or write new tests to exercise the new behavior.
Reviewing code is an incredibly valuable skill that everyone should get involved with. Do you have any tips that we missed? Let us know on Twitter. If you are interested in code review, check out the modern code review tooling we are building at Graphite. You can sign up to join here.
