Code Reviews: A Realistic Approach
Hey there!
If you’re a newbie reading this, you may not have come across the term Code Review before or you’ve probably heard it from other developers, so I’ll dedicate my next paragraph to you because I remember what it feels like to be you in this overwhelming tech space.
What is code review?
Code review is simply ‘reviewing code’ (I know, right). It is the systematic examination (often referred to as peer review) of computer source code, intended to find and remove the vulnerabilities in the code.
In a system where you work on a repository with other developers, after doing your stuff, commit, push and create a pull request on the VCS most likely using git commands, everyone takes a look to check if it’s okay for use, if so, they approve it get it to be used on the product.
Not one software engineer that I’ve spoken to in the industry has downplayed the importance of code review. So a question pops up;
Why is it so important?
The code review, primarily, is a check [by humans]
A wonderful engineer said,
“It makes you a man(human) in the software engineering world”.
Though no one is above errors, I’m sure you don’t want a console.log(user_data) or a var_dump($user_data);die; running on production because of the kind-hearted engineer who was debugging code (Trust me, this happens more than you think), neither do you want to have a wrong implementation of a particular flow because the engineer was having a bad day. The fastest and safest way to curb this is in code reviews. If you don’t see it, others should.
In organisations where a style guide and code convention is used, the code review is the ‘law enforcement agency’ that makes sure no one adding code compromises the standard thereby ensuring quality of code.
Bitter Truth: The quality of the code is the quality of the engineer
Code reviews sometimes seem like they slow down production or frustrate programmers, but the good outweighs the bad.
Apart from error and convention checks, what does a code review do?
Basically, code reviews check for a lot but I’ll highlight a few from what I’ve learnt from people and my experiences:
- Implementation of the task: Is this the best way?
- Algorithms: Can it be faster than this or can it take less space?
- Logic: What were you thinking?
- Flows: What steps did you take?
- Code complexity: I hope this is not complicated and hard to read and maintain?
- Backward compatibilities: Would this implementation break the previous version(s)?
- Performance efficiency: Would this provide a better service?
- The skill level of the engineer (You’d be shocked).
//Javascript Code Alet x = 3;
if (x > 5) {
let myvariablename = x + 1;
} else {
let myvariablename = 5 - x;
}
return myvariablename;//Javascript Code Blet myVariableName,
x = 3;myVariableName = x > 5 ? x++ : 5 - x;
return myVariableName;
The above code snippets do the same thing but they both scream two different skill levels.
Who needs the code review?
A few engineers think code reviews are for only junior engineers, as they might not have been deeply integrated into the required practices and conventions.
But most engineers which I happen to be part of, see is as a necessity. The senior engineers who those few think do not need it are the ones who disclaim ‘we also make mistakes` and ‘my way may not always be the best way’.
Code review is considered essential to the growth of a software engineer and must be maximized in usage by engineers. As an engineer, you should look forward to your code being reviewed and the results should be that your next pull request becomes better the last.
How to approach code reviews?
A good thing to understand that a human being who has emotions wrote the code. No matter who they are, I don’t believe anyone should be disrespected. It’s a code review, not a developer review. So what you, as a reviewer should focus on is what was listed above- code quality, implementation, etc.
Here’s a quote and few screenshots from a short survey I did:
It is extremely useful and it is also a very sensitive area in the industry, I believe people should write proper comments and also be careful not to attack people’s choice of implementation, in addition to the comments, they should give meaningful pointers as to how to fix the problem, an example code snippet wouldn’t be bad or a link to stack overflow. I would also like to add that you don’t have to comment on everything, make sure the things you comment on are extremely needed because some authors tend to feel attacked when you spam their PR (Pull Request) with trivial comments.
Almost 100% of developers that submitted their reviews attested to the fact that at one point or the other, they actually got hurt from code reviews.
So, dear reviewer, you may not like him, she may be inconsistent, he may be lazy, she may not pay attention to details but like a thoughtful engineer said,
A code review session can make or break the morale of a software engineer. If you’re the one doing the review, always remember your choice of words matters.
Code review should NOT be like judgement day, neither should it be a moment of jest, rather it should be a healthy critique (not attack) and exchange of ideas, questions and knowledge. It’s teamwork, remember?
This article is a the product of a short survey within developer circles from which I got a lot of very healthy responses I summarized. If I got your response, you’re the real writer behind this, the real hero.
Thanks.
