When a developer finishes a task, another developer analyzes the resulting code, taking into account the following questions.
- Is the code free of obvious logical errors?
- Is the code fully usable for all the use cases described in the code requirements?
- Does the added code sufficiently cover the new automated tests? Does the existing automated tests need to be rewritten to account for changes in the code?
- Does the code meet the requirements of the existing design guidelines?
Code checks should be part of the team’s existing workflow. For example, if it is customary for a team to create job branches, code reviews should begin after all code has been written, the automatic tests have been completed and passed successfully, but before the code is merged with the branch above. Then the person who checks the code will be able to pay attention to those parts of the code which are not covered by the automatics, and errors in the code will not get into the main branch of development.
Code review comes in handy for any team, no matter what development methodology it follows. No one member of the team is the only one who knows any part of the code base. Simply put, code reviews are a tool for sharing knowledge about the code base among all team members.
Code checks facilitate knowledge sharing
At the heart of all teams is unprecedented freedom of action, as all team members can take work from the backlog and execute it. As a consequence, teams are more enthusiastic about storming through new work because the tasks are independent of each other. Generalists can do both client-side and server-side work.
During code reviews, developers encounter new ideas and technologies, and as a result, the quality of their code increases.
Code reviews improve the accuracy of job complexity estimation
Recall the section on complexity estimation. The whole team is involved in this procedure, and when all participants know the product equally well, it is possible to estimate the scope and complexity of the work more accurately. When it becomes necessary to add new features to the existing code, its first developer can share his knowledge and give an estimate of complexity. Besides, all the employees who check the code get information about difficulties, known issues and peculiarities related to the code fragment they are interested in. Consequently, the checker has the same knowledge about that piece of code as the original developer. In this way, the team gets a lot of fact-supported baseline data, on the basis of which a more accurate and reliable final difficulty estimate can be given.
Checking the code allows for breaks in the work
No one wants to be the only person answering all the questions about a particular piece of code. Neither does anyone enjoy having to deal with a critical piece of code that someone else has written, especially during an emergency in the work environment. Code reviews promote knowledge sharing within the team, so anyone can take up the baton and get on with the job. But the main benefit lies elsewhere: if critical tasks are handled by more than one developer, it means that all participants in the process can take breaks from their work. If you feel held hostage by version control, code review is a great way to set yourself free. This way, you can take a much-needed vacation or devote time to another component of the product.
Code checks give you the opportunity to train new professionals
Another distinctive feature is that when new members join the team, they are mentored by more experienced professionals. During code reviews, they discuss the code base. Often the code hides knowledge unknown to the team. During the review process, they are discovered. The newcomers bring their fresh perspective and notice ungainly, overlooked because of lack of time, fragments of the code base that need to be reviewed. As you can see, through code review, new useful information is framed by existing knowledge.
Hint
That said, code review doesn’t have to be reduced to supervising senior employees over junior ones. Any team member can check the code of any other team member. Knowledge should have no boundaries! Yes, code checking can be useful for newcomers, but it should by no means be used only as a mentoring tool.