The power of reviewing

Photo by Markus Winkler on Pexels.com

Hey there! Evaluation time, how many times have you went back and check the code that you have made before? What about how many times did you sent your code to a colleague or classmate to review it? Today we are going to talk about exactly that, why you should care about it and do it for own good.

What is it?

As the name suggested, is simply letting someone read your code and point out possible flaws or improvements that can be done. Seems easy enough, but not really, there are many aspects that need to be addressed depending on the requirements of the project or the company you are working on, but one thing is for sure, if you are an entry level engineer or an intern, you probably need to learn from someone else.

What makes a good code review?

A good code review depends a lot on the interaction of the reviewer and the person being reviewed, the reviewer needs to have plenty of experience on the programming language or the code base to do a meaningful review where you can learn from, generally, if you are open minded about your knowledge, you will have a successful code review.

There is a good video I found explaining what makes a good code review, I recommend watching it since it covers important topics for people that are not familiar with it.

Youtube video. How to make a GOOD Code Review?

Additionally, there is a really good blog post by Palantir where he goes into detail about the Code Review best practices, I recommend reading it since it makes a lot of interesting points.

What is this useful for?

One of the mains things that we can do with this review is early detection or errors or improvements that can occur, this is were senior programmers can teach and make the junior programmers make mistakes that can potentially make an outage.

Apart from outages and testing purposes, one thing you will encounter a lot in huge repositories is the Code Health, where we need to make sure that the code is readable and maintainable as possible, because on most large projects you work on, at one point there will be another person that works on it, and if you don’t follow standards or styles, it will become almost impossible to maintain. I recommend this really useful blog post about this topic.

How can I do it?

First of all, a code review is to learn, keeping your mind open even if there is 30 comments on your first submission is fine, your reviewer is there to teach you, a common list of steps you follow before submissions is this:

  • 1st: Before you commit review your own code! You are using other people’s time here.
  • 2nd: Understand what you are changing.
  • 3th: Built and test yourself, do not try to do changes without this!
  • 4th: Comment your code! Especially if it’s a complicated piece of code.
  • 5th: Consider how the code will behave in production, not all code that works locally will do on production.
  • 6th: Do test and check build files! Testing is your primary focus, most of the people will enforce you to add tests to your own code or run some test of the main pipeline to verify that your change doesn’t do any harm to other elements.
  • 7th: Follow up on reviews fast!
  • 8th: Reviewers are not perfect, not all they say has to be the absolute truth, you can reply back your reasons if you have them, but do not take anything personal.

How does it look like?

Investigating the effectiveness of peer code review in distributed software  development based on objective and subjective data | Journal of Software  Engineering Research and Development | Full Text
Code Review workflow by Eduardo Witter dos Santos

As seen in the picture, the normal workflows has the following actors: Authors and Reviewers, and on most of the huge software companies, there are many tools that verify everything. First you request your review, this will normally be automated reviewed to see if it follows the style guides, doesn’t break anything, it compiles, etc., after that, the system sends to the Reviewer the code to check it, it it’s not ready it is sent back to the Author to do modifications, and this cycle continues…

Once the Author and the Reviewer are satisfied with the result and it’s ready for productions, it can submit (or merge) the changes to the code, which this is a whole process on it’s own for DevOps. There is an important thing to notice, the Reviewer can be multiple people, in my experience at Google we normally have three types of reviewers to be able to submit any code to prod, the Code Owner (owns the repository or folders where you make the change), the Language Reviewer (it’s certified as a reviewer for a certain programming language) and whatever other person (if needed). You can add as many as you want that are necessary.

Final Thoughts

In my experience, Code Reviews are quite scary at first but then you get the grip of them and realize how useful they are. At my internships at Google, I have experience these almost daily since it’s an essential task that you need to do, and I learnt a lot from it.

I hope that you find something useful for this post, and if you want to learn more, you can always comment on this post to contact me, thanks and have a nice day! 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s