loading...

How To Do a Code Review And How To Pass a Code Review

stefanovskyi profile image Oleksandr ・3 min read

Alt Text

Well, ok, so you know what a Code Review is and what is the purpose to do it, right?

Code Review is the process where developers reviewing each other`s code to detect misconceptions and potential issues before merging it into a stable codebase. The main goal of Code Reviews is to find quality issues in the reviewed code. Other goals which are also reached by performing these reviews are:

  • Improved code quality
  • Keep consistency in your projects
  • Finding bugs
  • Creating a sense of mutual responsibility
  • Finding way better solutions to problems

Code Reviews are a great way for teams to keep their software maintainable and also find bugs before they make it into production. First of all, we have to remember that code review is not judging or reviewing a person's ability to code.

Before creating a merge request do the code review of your own code it will save your time fixing it later and it also will save the time of the person who's supposed to review your code.
A shortlist with questions to ask yourself before sending your code to review:

  1. Did I implement the task correctly?
  2. Did I cover the code by tests?
  3. Is the code style standards followed?
  4. Is logic in the code I wrote could be simplified?
  5. Is the method/variable/class name is understandable?

Recommendations on writing code that easy to review:

  • Make small iterative changes
  • Link to documentation
  • Think about the readability of your diff
  • Don’t refactor in addition to new changes.
  • Check that your PR doesn’t have unnecessary changes or unrelated files.
  • each PR should be one logical unit of work

I believe that Code Review Principles and Best Practices should be shared within your team before you start doing code review.
Be friendly and make your comments precise but as short as possible. Make sure that it is about the Code and not about the Author. Avoid possession words like your, mine, my, they are easy to misinterpret and it really should be about the code. Make it clear if your comment is a request for change or an opinion, on which you probably need to discuss.

A shortlist with questions to ask yourself while reviewing the code:

  1. Have I read the ticket description? Is the code cover the task?
  2. Could the logic in the code be simplified?
  3. Is the code style standard followed?
  4. Why did this person write this code the way they did?

Recommendations before writing comments on code:

  • Put yourself in the other person’s shoes.
  • Listen to hear what’s actually being said.
  • Let go of what you think the outcome should be.
  • In your comments try to avoid phrases that could hurt the author.

Conclusion:
Most importantly of all, the goal of a code review is to have the code pass the review, and make it into production. Code under review is usually code that’s not being used, and code that’s not being used is not adding any value to the application or the users.
Write a good code is hard and review a bad one is even worse. Let`s do our lives easier and spend some time reviewing our own code before sending a merge request.

Posted on by:

stefanovskyi profile

Oleksandr

@stefanovskyi

Ambitious and hardworking software engineer with proven experience in Software development, passionate about learning new things every day and creating lots of interesting applications.

Discussion

markdown guide