How to conduct code reviews and give meaningful feedback

Tips and conclusions on how I developed my way of reviewing code from ground zero

Introduction

Two years ago, I started working in Azimo as an Intern Software Engineer of iOS. Before that, I had minimal experience of working in a team (university or personal side projects), so I needed to catch up a lot. One of the most crucial parts where I needed to gain more knowledge and experience is a code review. At that time, we were working in a two-person team — me and a senior engineer, which means that I needed to review his code. Only thinking about that gave me a frustration — how could I find any problems in the code written by far more experienced developer?

Fast forward, after two years of working here, I’ve learned a lot about reviewing code and decided to share my list of tips on how to do it effectively and make our feedback meaningful to your teammates.

1. Don’t be scared to review code from more experienced software engineers

No one is ideal — that’s why we cross-review our work. You cannot be sure that your code is 100% bug-prone, and even years of experience won’t make you infallible. We are people. Also, a fresh look is always very helpful because everybody has a different learning background, opinions, and life experience.

2. Plan when you want to start a code review

Code review is that part of work when you don’t want to be interrupted. When you are getting distracted every 10–15 minutes, there is a higher probability of not noticing some flaws in the code. Try to dedicate one hour of full-focus time (or more, depending on the size of code to be reviewed). I try to do it mainly in the mornings. Also, remember about breaks — give your brain some time to rest.

3. If you have a lot to review — do it by chunks

Sometimes there is no way to separate a huge implementation into smaller ones, remembering that someone has to review it. When you got a large amount of code, try to review it by smaller chunks. Give some comments, and when you think there’s enough — re-assign ticket so the person who asked you about the review will have some time to apply fixes. And later — review fixes and continue the process from the place where you finished it before.

4. Don’t be scared to ask questions when unsure

You should not hesitate to ask for clarification when something looks not okay for you. When something is so over-complicated that your peers cannot understand what’s going on in the code — maybe it’s time to consider some refactor? Code review is also a great chance to learn something. After all, there are no stupid questions. 🙂

5. Typos and wrong names are as much important as every other mistake

In the ideal world, your code should be as readable as a book. New joiner of your team or a person who reviews it should not hesitate about what given function does and why. It should be deductible either from well-written documentation, or the function’s name.

Now, would you enjoy reading a book with lots of typos and mistakenly chosen words? I don’t think so. If you noticed something that doesn’t sound well or could be improved — point it out. Names of functions that return a Boolean value should be questions; object names should reflect their purpose (`Builder` should build, `Model` should be a model with no other responsibilities). You don’t need to be a perfectionist, just try to keep your codebase in order — you will not have time to do it later. Believe me.

6. Remember to praise your peers

Don’t think of code review as just a process of finding flaws in it. Consider it more as a process of giving feedback. If you find some solutions interesting or you see considerable progress in your colleague’s code — write a comment to let them know. It’s nice to have this kind of acknowledgment in your team; it will be especially motivating for someone who is just starting his career. But don’t hesitate to praise the senior engineer’s work too. :)

7. Asking a question or proposing something is better than complaining

When writing comments to the code, I’m trying to use phrases like “What do you think?”, “What if …?”, “How about …?”, “Consider ….”. These phrases will stimulate your colleagues to think about other solutions and are a great starting point of the discussion. Complaints are blockers for active thinking and the discussion in general.

Like in this simple case:

let transactions = ... //array with lots of items
for transaction in transactions {...}

giving feedback like “Consider using map instead of for-in for better performance” sounds better than “You should’ve used map”.

8. Don’t postpone code review too much

Of course, all of us have a lot of cool new features to implement. But it’s more important to deliver as a team, not as an individual. Don’t make your colleagues wait for a review from you. Otherwise, you will end up with 4–5 merge-requests per person in the “To Review” list (which is a lot for a relatively small team).

I’m trying to organize my review workflow in this way:

• If I got a code to review and it’s our weekly priority — I’ll start reviewing it ASAP.
• If I got a code to review, it’s not our weekly priority, but it’s relatively small or a quick-fix — I’ll start reviewing it the same day I got it.
• If I got a code to review, it’s not our weekly priority, and it’s a big feature — I’ll start reviewing it the next day I got it.

Also, It’s good to define some kind of “internal deadline” for review in your team. Like, if your code was not reviewed in the last two weeks — you can merge it without a review.

Conclusion

This is the way I conduct code reviews now. Everybody in our team tries to bring something new to our review process. Someone adds automatizations. Some share time-management tricks. We all together set up constraints that help us to create a clear and standardized process. Most of the time, everything works pretty well, and our reviews’ stack is not overflown.

Of course, the process I described is not ideal (I’m not sure if there is such), that’s why we never stop iterating over it. We are always very open to feedback, so If you have any questions, suggestions on what can be changed or you just want to share your experience — leave a comment :)

Towards financial services available to all

We’re working throughout the company to create faster, cheaper, and more available financial services all over the world, and here are some of the techniques that we’re utilizing. There’s still a long way ahead of us, and if you’d like to be part of that journey, check out our careers page.