How To Implement Code Review Process In A Web Development Team

by Paul Naumenko

Web development is effective in terms of business if it delivers the good product within expected costs and timeframe. A web development studio gains reputation only when their product works flawlessly ever after.

One of the obstacles all programming teams experience at a certain point in their history is code style discrepancy. You’d think there would be nothing wrong with that. Coding is as much art as it is science. All programmers choose the code styles that work for them, and that’s how they do what they do.

However, in a team of programmers, different code styles will lead to lack of comprehension of your code by your partners. And this usually leads to:

  • Bugs in the collectively written code;
  • Extra hours of bug tracking and code fixing;
  • An unfriendly atmosphere inside the team due to mutual accusations.

In order to come to the “one size fits all” code unification, web development companies must embrace and implement the process of code review.

What is code review?

Code review is complex proof reading and verification of the code chains produced by team members. It is usually done by one or two experts (either team leads or senior programmers), and aims to harmonize the collectively written code. In the course of code review implementation, all of your team members eventually gravitate to the common style and programming principles. This will let anyone on your team understand the project as a whole, and be able to contribute to, or alter the existing code chains.

Who needs it and why bother?

Code review is crucial for every web development company that wishes to produce anything bigger than a landing page. The code is the skeleton of every digital product, and the later the project stage – the more costly and time-consuming it is to make code alterations.

Some may argue that professional programmers do not need to be proof-read. But this is not about professionalism, it’s about teamwork. Furnished and standardized code is the backbone of the future product’s stability. So, the earlier you realize you need code review – the more problems you will avoid in every other stage of your project development.

Who is qualified for it?

There is a programmer saying, “Wrong code is the one not written by me”. In order to analyze and evaluate the other’s coding efforts, a reviewer must have decent programming experience and a bucketful of successfully completed projects behind his back. It is important that such person has:

  • Vast experience in various project types. You won’t qualify for code review for the online store project, if you’ve only done news sites before;
  • Decent work experience in your team. You don’t truly learn all the company’s coding peculiarities until you’ve been a part of a handful of its projects.

At the very first, the role of a code reviewer is assumed by the team lead. As much as team leads may hate spending time on code review, there is no running from it. Later, when you bring up some of your middles to the senior level, they may - and have to be - also assigned for code review.

How to code review - Vintage’s experience

Before formulating the common coding principles and implementing the code review standards, we faced the following troubles:

  • “Time is of the essence, so I’ll write it my way, and then fix it later”. Fixing something is always more time-consuming than doing it right from the start, and this cannot ring truer for code writing.
  • “Where did all these bugs come from?” Code discrepancies tend to show up in later project development stages, and when they do, fixing things becomes much more complicated.
  • “Would you write a decent code, please?” A team is not productive when everyone argues over each other’s coding style.

At some point, we could not bear it anymore, and realized that only the competent code review approach would save the situation. Code review implementation included these basic stages for us:

  • Selected the common basic code style. To avoid inventing a bicycle, we agreed to utilize the core-team Yii2 style.
  • Approved the code review checklist that would be obligatory to follow.
  • Installed the automatic code review tools for PhpStorm – CodeSniffer and MessDetector - for all team members.
  • Agreed to conduct code review minimum once per week, and up to 3 times per week when needed. Assigned one reviewer for 3 to 5 team members. Made every reviewer study and follow the basic code review tips. A good example of such can be found here.
  • Agreed to use a single version control system for all projects, and selected Git for this purpose. Since all our projects are stored on Bitbucket, we use its innate capabilities for code review.
  • Made it a rule to have a separate JIRA ticket for every code review report. Set a 2-day period for every review to be implemented into the relevant code piece.
  • Decided that all proposed alterations and new rules must either be adopted collectively by all team members, or by no one at all.

As a result of code review implementation, we were able to achieve the following:

  • A single, unified code-style for the whole team. New team members integrate quickly and easily, since there is a clear set of rules and requirements everyone abides by;
  • Code review timeframe is approximately 6 hours a week per one reviewer, which is a lot less than we spent on bug elimination previously;
  • Better teamwork environment. No more mutual accusations of writing “bad” code pieces.

From our experience, the hardest part of code review is getting used to doing it on a regular basis. However, when you put in on the conveyor, you’ll regret only one thing - that you haven’t done it earlier. Your programming team will become way more flexible, productive and friendly, and will meet timeframes and deadlines with remarkable ease.

To sum it up, here are the five perks your company will get for implementing the code review.