How to make code review smoother

How to make code review smoother

Home / Mobile Development / How to make code review smoother

In this article, I will answer the question of why code review helps you grow and how to get the most out of it.

When you’re working on a feature, without showing it to the world, you don’t get any feedback. The same applies to building something or inventing other breakthrough things. You think the code that you’re honing is a game changer. However, if out of the blue, somebody comes over and whispers to you: ‘it ain’t gonna work, dude!’ By default, you set yourself up for failure, and the reason is quite straightforward: when working alone you can’t see obvious things. Writing code is all about collaboration and making things a little better. You can’t learn anything without receiving effective feedback.

Constructive feedback helps you grow

Let’s consider then, what you can do the next time you start a new task. You write the code and test locally, then when you’re sufficiently satisfied, you are ready to create a pull request. Tested code is the bare minimum, but to help your reviewers, consider the following steps. Write a description of why you made the changes. The ‘what’ is your code. However, answer the questions: why did you write it that way? What’s the business value? Other developers might not see the broader context and your role is to explain it to them. The description may also contain: a link to a ticket in an issue tracking system and/or a link to a test suite. Once you have completed that information, you’re ready to assign reviewers.

A good strategy is to cherry-pick developers. You don’t always have to assign a senior developer, as the knowledge in a project may not spread to a team. You can ask less-experienced developer to provide fresh-perspective feedback. It could turn out that the least experienced developers could provide the best outside-of-the-box feedback.

Be polite when receiving feedback. The intention isn’t for reviewers to make you feel guilty about the work you did. Nor do they want to point a finger at your code and say: ‘it sucks, man! You’d better send it to the Wayback machine for future generations!’. If you don’t understand the feedback, ask for greater elaboration from them. The reviewer may not have seen the broader context. When you are the reviewer, don’t just assume, but ask instead. Ask why the code was written that way. Provide hints and suggestions like ‘what do you think of this?’. However, If code review is taking too long, consider pair-programming or video conference. For me, pair-programming is the best way of applying feedback and solving problems. If possible, do it in-house.

Hint: When you see that nobody has given you feedback, ask them directly.

When someone comments on your code, gives you a piece of advice, or a hint, and you’re open to apply that feedback, you grow as a developer. Don’t be discouraged when you stumble upon the same feedback over and over again. This is how we learn—by correcting ourselves in response to constructive feedback. There is, though, some feedback that will get on your nerves: typos, missing commas, bad formatting, and the like. You can avoid these comments by knowing what constitutes a good code review.

Making code review smoother

Now that you know that a properly described pull request and tested code is a minimum. To make the whole process smoother, let’s see what constitutes a good code review. Reading code is time and energy consuming. Give yourself a pat on the back and consider:

  • Keeping changes small.
  • Harnessing code linters.
  • Things to pay attention to.

I’m sure that there isn’t a single developer on the earth who wouldn’t struggle with reviewing thousands of lines of code. Short-term memory capacity is very limited and if you have to analyse three thousand changed lines, your mind, will no doubt, switch off. Remember, that you have to see the bigger picture of what’s going on in the pull request. This requires that you  jump around the code and re-review it. If you post small changes, other colleagues don’t need to review a big pull request many times. The takeaway is always: keep it small! Otherwise, somebody will end up asking you to split the changes into a few pull requests. Bad for you!

Automatic tools are a perfect solution to avoid getting the feedback comment: ‘Cut the empty line!’, ‘missing comma’, ‘Fix tabs’, and the like. Code linters, optimizers, or beautifiers, will not only make your code more bulletproof, but they’ll save other developers’ time. For ruby consider rubocop, for JavaScript, ESLint.

Small changes and applying code linters will result in the limiting of the amount of time spent on reviewing changes,  result in faster deployment, and releasing a new version sooner.

Almost every project has a guideline which contains a list of rules that your code should adhere to. When you are a reviewer, ask yourself if:

  • The code has been covered through testing.
  • Clicking through the app is needed.
  • The code can be refactored.
  • The code is self-explanatory.

Remember that someone, probably you, will have to maintain the code in the future. When you give it a lick and a promise, a technical debt cumulates. You’d better take it seriously. In the end, you will save lots of time.

Other strategies

In many projects before merging changes, you have to obtain a given amount of thumbs up (approvals). This helps to avoid the situation where new code is deployed without any code review. The project, I’m working on now requires two approved reviews. As mentioned earlier, consider, if possible, cherry-picking developers for a review. If the feature you’re working on means it’s best to assign the most experienced developer, go ahead and assign him. However, don’t overlook asking for the least experienced guys, though! Pairing with someone in a way where you have to explain your solution also challenges you. Thinking aloud makes you stop and think if the solution you applied could have been written better and simpler.

Good code review is beneficial

A good code review is beneficial for you and your team. Asking for feedback will allow you to progress and learn from others. Often your colleagues will amaze you with a novel solution you could have used. Simple strategies applied to the review process will streamline reviewing and allow you to deploy changes faster. Last but not least, learning how to give and accept feedback will save you lots of unnecessary assumptions and frustration. All these things come with time and experience, so go ahead and show those changes to the world!

Wojtek Ryrych

Software developer and creative writer. Passionate about typography and clean design. After work he spend time on outdoor activities and experimenting in the kitchen.

More Posts

We use cookies to ensure that we give you the best experience on our website. If you continue without changing your settings, we'll assume that you are happy to receive all cookies from this website.