My First Impression about Code Review

My first time to know about Code Review is when entering my current company at Kurio. In my past company before here, we never doing any code review. So everything is just passed to staging-branch and if tested well merge directly to master.

Here in my current company, we trained to do code reviewing for every team member. So everyone can review when there is an open pull request (PR) .

The flow is simple, when you finished writing your code. You just make a pull request at github, then the entire team will review it.

If your code looks dirty and too complicated, well, your code will rejected by the teams.

Increasing Code Quality

If I remember how I write code before know about Code Review compare to how I write code now, its quality totally different. A few years ago, when writing some of code, I just write it how I like it. I don’t care about the pattern. Or when naming variable just named it with just x , y , z . Compare now, if I use a weird variable name, my code will rejected by the team. Every variable must descriptive, so every team will understand what it’s use.

Not only our code’s quality increased, also our knowledge and understanding to our code also increased. Because, when the team review my code, I must explain to them, what is exactly I’ve done. What is my function expected behavior. So I can’t just copy paste from StackOverlow.com or from other resources. I must understand and explain it to the team every code I write.

Fun and Fair

Doing code review is fun and fair to each team. There is a time when you were reviewed by the team. And there is a time you review another member.

Well, when review another code we must careful, we can not just say it wrong or rejected. Or we can not just accept/approve it, because when we approve it, if something unexpected things happen in production, we (both the reviewer and the programmer who submit the PR) will take responsible for anything happen.

By this code review concept, taught me to be more idealism and responsible for the system and every code written there, not only every code I wrote, also other’s code.

Another reason is, you have control on the projects. You can reject or agree for any submitted PR, fun and fair doesn’t it ?

Help Junior and Onboarding Engineers

Another thing that a good side about Code Review is, help the junior and onboarding engineers. There was a quote :

“For the things we have to learn before we can do them, we learn by doing them” ~ Aristotle, The Nicomachean Ethics

It just the same with Code Review. With this kind of method, every junior or new engineers can taught easily if they doing it directly instead just listening about the system, and anything that make us bored.

As for me, before entering my current office, I never created a unit test for any function I created. But after doing the Code Review, I started and must making my unit test, or my PR will rejected. It was very bad in the beginning, all my seniors reviewing my code, and rejected many times. Also, when they reviewing my code, they always give some advice and any principle that used in our company, might be about the test, the clean architecture and many more.

Within a month, I can see my code was improving dramatically. I am more care about test, and architecture. And it was very good for me and also for the team.

Pressure and Tired

However, doing Code Review also give you a bit stress, or maybe tired because your PR was rejected. For the first time when doing this I got many times rejected and requested to changes PR. I didn’t follow the standard, I just code as my mind want it. Then, for a single function that I developed, it could have up to 10 comments and revised. Well, it can make you tired, frustrated.

Later, when writing new code to merged, I will more careful and must looking for the best practice and pattern. The pressure is too high because our code will reviewed by the entire teams. It will force you to write an efficient code.

Sometimes, it also boring and make me upset. As we know, some of programmer have it’s own standard and perfection. For example: programmer ‘A’ doesn’t like to see any smell and messy line of comment, so he will reject my code because I have a few line of unnecessary comment. Even it was an explanatory comment 😈

Reduce Delivery Time

When using the code review concept, we will add more extra time for delivery projects. Because just for a little changes, must reviewed and approved by others.

Compare it when coding without code review

When coding without using the code-review method, it’s just easy, when the function running well on our local, we just simply push it, and if something conflict, fix the conflict, then merge into master branch.

I’ve a funny experience when making a PR to our base branch in one of our projects. It’s just to change a line of code. But, I must creating a PR then wait for someone reviewed and approved it. If every members is busy, then I must wait until someone is free, and can review and approve changes.

This kind of method, will reduce our productivity, especially when our PR still not reviewed, then we must blocked for doing anything. We just like stopped, and doing nothing until someone is free and review our code. But in other side, our code is less from messy and dirty code.

Conclusion

Last but not least, Code Review is a good thing for a good quality both for team and product. You can achieve the dream team, that know all the whole system by doing Code Review. But, in order to get there, you maybe will faced with a long timeline.

Code review will reduce the delivery time for every projects. As a Software Engineer, I recommend you to try the Code Review, even people think Programmer have no life,or identically as an introvert but with this kind of method, will give you a new skill : how to explain your code well and understandable.

Previously posted in: https://blog.pairworking.com/my-first-impression-about-code-review-ccca71ebd622