Git & Code Reviews

Lessons I Learned as a Code Reviewer

We are human, and we can make mistakes

Lessons I Learned as a Code Reviewer
Photo by Alvaro Reyes on Unsplash

Review your code first before asking others

I used to open a pull request (PR) as soon as I completed my implementation and requested peers to review my work.

No “YOU” attitude while requesting changes in pull requests

It pisses me off when somebody writes in my pull request.

why haven’t you close the connection?

why haven’t you added try-catch block?

I understand their intention that they are not impolite but simply raising their concerns. However, this “YOU” attitude is something that bothers me a lot.

As per my understanding, this code is not closing the connection 🤔

Adding emojis helps and reflects somewhat politeness.

Do you think it would be a good idea to surround this code block with try-catch?

Raising a question reflects that it’s just an opinion, and you may disagree with me. You could justify it by answering my question.

I’m sorry. I am not able to understand this piece of code.

The use of “I” reflects that I cannot understand it. Maybe I lack some domain knowledge necessary to understand this implementation.

Please, have mercy on the code reviewers

If you are working on an extensive feature, please think twice before working on it. And split your pull requests (PRs) into smaller commits — no more than three commits per PR.

  • Increase the readability of the current implementation.
  • Pay close attention to unit tests and improve them if necessary. Unit tests are crucial to understanding any feature. The poor unit test makes it harder to understand the implementation and might add technical dept.

Be honest and say it louder & clearly

Before reviewing any pull request (PR), I skip and skim. It gives a first impression of the implementation and how much time I need to invest in this PR.

Please note that I am not impolite here.

Sorry, I am not able to understand this implementation. It’s harder for me to follow.

It is also feedback. If it's harder to understand for any members of a team, one should re-structure code or organize it into smaller commits.

Conclusion

Code reviews are crucial, in my opinion. While reviewing the code, I have the mindset that I might have to work on this feature tomorrow. If I cannot understand it now, I will not be able to understand it tomorrow.

Want to connect?
Facebook | LinkedIn | Twitter
Subscribe to get my work directly into your inbox.
https://medium.com/subscribe/@anasanjaria

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store