Code Review Culture
Code Review tips for productive Code Review experience
This article is a small essay, where we will talk about a Code Review culture, communication, and skills of code reviewer. At the same time it is not a step-by-step instruction of How exactly do a Code Review.
Hi, my name is Vlad, I am an Engineering Manager at Agoda. During my career path at Agoda from a Senior Software Engineer to Technical Lead I did more than 1100 contributions every year. My Code Review experience got increased significantly.
Code Review is a dialogue between code author and code reviewer. Effective dialogue can turn an ordinary Code Review into exceptional learning. Lets see how.
Code Review Communication
When the code author requests for a Code Review, he or she basically expects an Approval. If you are a reviewer, who really wants to help the author to do a job, you need to make a decision: Approve or Reject. This simple binary-mode decision-making process will set a Code Review experience on rails of constructive actions from both sides.
Don’t Compromise
My first advice — make a decision: Approve or Reject. Code review with a Comment status does not help either you or the author. Comment status may only be a signal of your uncertainty or unwillingness to take responsibility.
Don’t waste time. If there is nothing to fix — Approve. Sure, in most cases, there will be some code-fix proposals. If you think, that all your code-fix recommendations are not mandatory code changes — again, Approve the code. Indeed, if you think, that author can ignore all your comments — Approve. Otherwise — Request Changes.
As a reviewer, you have a power of Reject (Request Changes). Use it every time you want anything to be changed. It does not matter what change you want: a formatting change or ask for a complex refactoring. If you want any change to be done — request for those changes. Simple.
Communicate
Request for changes is aimed to improve a codebase, prevent mistakes and share knowledge. When Code Review Reject demotivates or slows down the development — you need to improve communication. There is no problem with Rejection itself, but can be a problem with how fast you communicate with each other and the quality of the dialogue.
Reject and forget about the next Code Review round is a bad idea. Once you Reject, you should be responsive 24/7 to make the best experience for the author. Author should get your Approval immediately after all your concerns being addressed. Fast reply is a code reviewer responsibility.
Another bad idea: to check one line of code and request one change, without checking all the rest of the code. Please, validate all the diff and request all required changes in one shot. Don’t turn the process into a Ping-Pong.
Create
If you are building something big together — build a process around a Code Review experience. Provide a “Code Review as a Service” to others. You can use dedicated communication channels for Code Review requests and On-Call duties with help of bots and process automation. I highly recommend you to set a reasonable SLA for a Code Review response time. It will help you to control and execute Code Review duty with excellence, collect data and improve results over time.
Code Reviewer Skills
Now lets talk about the best skills of Code Reviewer.
Result of Code Review fully depends on the professional and personal skills of the Code Reviewer. It is a hard work to provide a good Code Review message for every Pull Request, but you should try every time, again and again. Keys of success are: good codebase knowledge, good memory, good mood. Now, one by one.
Become an Expert
It may sound a bit epic, but you really should know what a hell is going on in a codebase. You should know the aspects of programming language, have a framework platform perfect understanding, plus project architecture, and finally the business domain. Deeply. There is no any magic.
Work sincerely every day to become a codebase expert.
Stop and Analyze
Unfortunately, not every developer knows existed codebase well enough. Carefulness to the details and a good memory will help you to become a special one. During a Code Review process we only see a code changes, while the whole codebase is hidden from the eyes of the reviewer, so you can rely only on your memory. You need to keep a main chunks of project in your head, remember who’s doing what, synchronize several initiatives.
You don’t need to sit at night and try to memorize a codebase of a particular project. Train your brain in general. You can challenge memory by reading many books, playing and analyzing board games like chess; an extremely useful way to train your memory is to learn a new language (Japanese, for example).
Respect
Never write a Code Review with a negative, emotional, or destructive tone. It may kill a communication, rise a conflict, can hurt a person’s feelings (de-motivate, resent, angry). It will impact your reputation.
Be polite, constructive, use a positive tone. When you suggest a change, you need to explain why. Use code snippets, examples, and references. Perfect, if you can share a link of Code Guidelines or Code Standards.
Bonus
A few good habits of code contributors.
Let your code to be reviewed. Code Review is just a Code Review. There is no place for your ego. Code Review is about cooperation and open-mind. Remember, that both sides are interested in better result and knowledge share.
Summary
Practice in a Code Review daily. Learn a codebase. Stay tuned with things changing in the project. Be a humble and positive person. Very soon you will notice: the number of happy engineers around you will drastically increase.
Cheers.
