This content originally appeared on Level Up Coding - Medium and was authored by Mohamed Aboelez
Good code reviews nurture teamwork, help developers grow, and improve app quality.
One day, I got promoted to a senior developer and was asked to include code reviews as part of my duties. I then realized that my experience had not prepared me to be on the other side.
I developed cold feet and felt like an imposter every time I was asked to do a code review. Multiple questions tormented me.
Should I comment this line of code?
I think there is a better way to write the class. Should I tell him?
What will he think? He is more experienced than me.
Will I crash the application by changing this code?
That was when my mentor advised me.
Good code reviews focus on unexpected outcomes rather than the one-track focus on finding bugs. Do not treat reviews as an interrogation. Rather let code review policies be guided with the explicit intent to improve code style, find alternative solutions, increase learning, and share ownership.
As a reviewer, your feedback in code reviews is one of the primary ways to build a community of developers eager to contribute. By nurturing a strong community, you will promote a quality product, a quality team, and a quality life.
Here are some aspects of doing a good code review.
1. Set goals and capture metrics
Scott M. Graffius has rightly said:
“If you don’t collect any metrics, you’re flying blind. If you collect and focus on too many, they may be obstructing your field of view.”
The key is balancing how you gather metrics. Too many metrics is a waste of time, and no metrics is like sailing in a rudderless ship. Before implementing a process, your team should decide how you will measure the effectiveness of code reviews and name a few tangible goals. As a rule of thumb, good code should be:
· Functional first — it should work as intended
· Clean and maintainable second — readability should be high
· Optimized third — perform as expected in production
The metrics defined should have goals to ensure improvements are measured and tracked during and after the review. For example,
“Reduce support calls by 15%,” or “cut the defect injection rate by 50% during development.”
Remember, the goals should give you a quantifiable picture of how your code is improving. “Fix more bugs” is not a tangible goal that will not add any value. As Albert Einstein tells us aptly.
What gets measured will only get managed.
2. Criticize ideas, not people
Frank A. Clark stated:
“Criticism, like rain, should be gentle enough to nourish a man’s growth without destroying his roots.”
Why do code review discussions sometimes go out of hand and become emotionally charged?
It happens when we stop discussing the merit of an idea and start discussing the person who created that idea. It is always easy to say, “you, you are stupid, why did you not implement the code for concurrency.” And it actually takes grace, poise, and maturity to say,
“I am curious about the way you implemented this code. How will this code handle concurrency?”
The difference is obvious. In the first approach, you are shaming a person and giving him the ammunition to enter into an open-ended argument. In the second approach, you are only talking about the code. There is no judgment or no accusation, just a plain clarification.
Remember a small amount of politeness and courtesy goes a long way in having a meaningful conversation with the person. Ensure focus on the pure merits of an idea, and don’t get consumed by tribal vendetta and personal politics.
Keep it professional, not personal.
3. Question until you understand
Kubra Sait said:
“Asking questions is the first way to begin change.”
If you are not familiar with the application, you cannot do a good code review. Simple as that.
You need to look at everything that you think may be relevant, irrespective of what others may think. This will require you to go deeper, ask questions, and confirm your understanding at every step.
You are like a doctor who is treating a patient. The doctor asks various questions — your habits, what you ate, your stress levels, the medication are you taking, etc. Then she suggests improvements. The human body is a complex engine and unless the doctor is persistent, he can never get into the root cause of the problem.
Code reviews should also work in the same principle. Nigel Munoz, a former full-stack engineer at The Muse and a current freelance software engineer, encourages the reviewer to think about “how this change affects the larger and smaller picture.” Considering the larger picture includes finding any code that is repeated, non-modular, or does not adhere to the standard conventions — as well as analyzing modifications to the architecture of the codebase.
Do not just accept what has been told to you at face value. Keep questioning until your knowledge about the code equals to that of the developer.
4. Don’t spoon-feed
Maimonides stated:
“Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.”
When you are doing a code review, you are also playing the role of a mentor, and good mentors teach, they do not spoon-feed.
There are several advantages to this approach.
· Code reviews become a learning and sharing session.
· The developers take complete ownership of the code instead of relying on you to help them with the solution.
· You are creating and nurturing the next wave of talented senior developers.
Once the whole team adopts this learning attitude, you will soon find the intellectual capital rising within the team. This also makes healthy use of the ego of the developer. This “Ego Effect” naturally incentivizes developers to write cleaner code because it gives them an opportunity to showcase their knowledge that they have assimilated on their own and which they are proud of.
5. Lastly, do not review code for longer than 60 minutes
Garry Kasparov says it nicely:
“The ability to work hard for days on end without losing focus is a talent. The ability to keep absorbing new information after many hours of study is a talent.”
Do not make code reviews as an epitome of drudgery. If your capacity to absorb knowledge is deteriorating with every passing minute, that only means you need to take a break and reset your mind to its full capacity.
It is best to conduct reviews often in short bursts of sessions.
Do not review too many lines of code at once; you are less likely to find defects.
Doing frequent reviews will not only improve the code base but also allow you to take time and identify the best solutions to every problem instead of zeroing on the very first solution that comes to the mind.
Lastly, make code reviews a positive affair. Celebrate the fact that bugs have been reported long before they made it into the product which would have resulted in an unhappy customer. It does not matter who or how that bug was introduced. What only matters is that you and the team have been instrumental in creating a better product. Be proud of it.
Fostering this positive culture will go a long way in making code reviews a collaborative, collectively owned activity in which the team would appreciate (rather than dread) code reviews.
As Hellen Keller stated:
“Alone we can do so little; together we can do so much.”
Level Up Coding
Thanks for being a part of our community! Before you go:
- 👏 Clap for the story and follow the author 👉
- 📰 View more content in the Level Up Coding publication
- 🔔 Follow us: Twitter | LinkedIn | Newsletter
🚀👉 Join the Level Up talent collective and find an amazing job
How to Make Good Code Reviews Better was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Mohamed Aboelez
Mohamed Aboelez | Sciencx (2022-11-15T03:29:07+00:00) How to Make Good Code Reviews Better. Retrieved from https://www.scien.cx/2022/11/15/how-to-make-good-code-reviews-better/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.