Code reviews can be done in different ways across companies with various managerial approaches in different cultural environments. Of course, this practice impacts the company’s culture, the professional growth of teams and individuals, and, all in all, the results of your work. This article provides you with a list of practical tips for developers, project managers, product owners, testers, and other team members. Let us dive right into it.
Karl E. Wiegers begins his classical essay on peer reviews with the manifest:
“After experiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them.”
Meanwhile, many companies are reluctant to practice code reviews given the time scarcity. But we believe that in reality, code review fosters better results during a shorter time. We’ll tell you how.
When working on a new feature, Alex cuts a branch from the master product to work on that branch only. Later, when he decides to integrate that branch into the master, another qualified engineer, Julia, looks at his code and gives a blessing for it. They probably would discuss and try several iterations before Alex’s result was submitted to the master.
Thus, code review provides the answers for the question like:
- Are there any logic errors in the current code?
- Considering the requirements, are all cases wholly implemented?
- Does the updated code follow the existing style guides?
- Do your automated tests cope with the task of a new code?
- less time spent on rework
- more programming productivity
- less debugging and unit testing time
- less debugging when integrating and system testing
- better new techniques learned from colleagues
- all the team members can stay on the same page during the project
- focusing on minor defects, since the quality of the product is higher
- better test design
- fewer defects blocking continued testing
- shipping the product in time
- shorten the time of any software development methodology projects
- less customer support and field services costs
- more time for new development projects
- enhanced teamwork and overall effectiveness
- knowledge sharing among team members and minimizing the effect of staff’s turnover
- an in-advance vision of potential risks
- a better understanding of the project thanks to participating during the development phase
- less time spent on supporting and fewer tasks in the backlog
- better and more logical results that are easy to understand or change per request
- a robust culture that welcomes changes
Benefits of code review for your team
To start with, consider both the mechanics of the process. Later we will talk about the “spirit”, as code review is more about your soft skills, we propose to follow the tips for fruitful and harmless collaboration.
Ideally, code reviews are more productive when integrated within the existing processes of a team. For instance, whether you are using tasks branching workflow, conduct code review when all the code has been designed, and automated tests run and successfully passed. Only after that, merge the branches with the master code. Meanwhile, it is easier said than done since the programmer’s ego enters the picture. But we know how to indulge it!
Egoless programming, not a programmer for more openness
Code review sets a bar everyone at the company should consider. Thus, everyone in the team is open to scrutiny from the other. Of course, it is natural to avoid the critique, but you should bear in mind that your colleagues are criticizing your work, not your personality. Gerald Weinberg coined “egoless programming” in The Psychology of Computer Programming, published in 1971. The author points out that people used to tie up their personality with their work and see the shortcomings of their code as personal drawbacks.
Thus, a developer is guarding their ego and setting the barrier to the effective code review, leading to poor results. But “egoless programming” enables the developer to zoom out and let other colleagues point out the parts needing improvement. However, we do not mean “egoless programmer” with “egoless programming” since developers should trust themselves and defend their work but not reject ideas for better solutions. Simultaneously, egoless reviewers should demonstrate empathy for their colleagues, since their roles could be reversed once.
Code reviews foster high standards, social recognition, and security standards
Code reviews promote psychic flexibility and help to hold the same set of high standards in the team. Just by saying to ourselves that we expect high standards from everyone on board, we create an atmosphere fostering professional development. Coworkers want to reach the high bar, not simply pass the reviewer. Thus, delivering a carefully crafted piece of code to your reviewer becomes crucial, not just a typical LGTM. Also, polishing your tone as a reviewer to provide even the harsh feedback is a valuable skill.
Moreover, code review helps to foster social recognition that leads to better results of the work. Finally, since only qualified developers are conducting reviews, it becomes a valuable asset to assess someone’s work and get the feedback to become a seasoned professional.
Besides, code reviews require both the reviewee (developer) and reviewer to monitor the updates in the security domain and use that knowledge in the natural environment. Thus, security also joins the tasks with high priority.
- You are the primary reviewer as an author of your code.
- Create your checklist — one that follows the coding standards of your company, focusing on your areas of development as a professional.
- Do not take the flaws of your code personally. Products of your work are not the parts of your personality.
- Know the difference between rewriting code and fixing code, do not rewrite it before the consultation.
- Everyone makes mistakes, so do you. Just learn how to accept them.
- Everything is changing. Learn to accept these changes.
- Code review does not mean problem-solving.
- Make your contribution to the coding standards — when something arises that is not mentioned in the coding standard, do include that to prevent similar things to crop up again.
- Does the submitted code correspond with the goal it is supposed to reach? Every change should have some reason (fixing a bug, introducing a new feature, etc.)
- Ask questions when something is needed — what if the developer has forgotten to comment on some parts?
- Think of the problem you have solved while reviewing, is there any pattern you have noticed but not reflected in the current version of the code?
- Changes that you have done should follow the existing standards. You can always add a comment that the changes committed to following the current patterns.
- Heavily scrutinize the changes leading to the dependencies, as we want to have them as few as possible.
- Concentrate on your reading experience. Could you grasp the concept in a short time? Is naming clear? Are method names and variables easy to follow?
- Read the test that should be done before the review. If not, ask a developer to perform one.
- Provide feedback in comments, commit messages and on-code level documentation.
