Among the various quality approaches implemented at Novaway, code review is one of the most deeply rooted in our processes.

What is the magazine? What is it?

Code review is a review of a piece of code before it is added to an application’s overall source code. This review aims to detect (among other things) non-compliance with good practices, architectural weaknesses, forgetting “dead code”…

Who uses code review?

Code review is a fairly common practice in development. This practice can be implemented regardless of the size of the teams. Several big names have implemented a code review policy:

• Google, with a very specific policy
• Cisco
• Intel
• Nasa
• Novaway;)

Code review in figures

33: it is the number of maintenance hours that can be saved by one hour of review

60%: this is the average number of bugs detected by the code review (compared to 25% by unit tests and 45% by integration tests, which are not to be neglected because they have other virtues: non-regression, living documentation…)

The benefits include

Having a successful code review policy takes time and may at first appear to be an unnecessary cost. However, it offers many advantages, some directly visible, others more latent:

• The quality of the code is obviously improved, it becomes more maintainable, better structured
• As mentioned above, the number of bugs is reduced;
• Communication and collaboration between team members is enhanced;
• Code reading has a formative aspect on the project team;
• The knowledge of the project is correctly distributed throughout the team.
• Good practices
• Implementing a code review policy is fine, but a poorly implemented code review can become a burden more than a benefit. Everyone has a responsibility to ensure the success of a good review, both the requester and the reviewer.

As a plaintiff

• Stay atomic. We tend to say that a 100-line review is done in 15 minutes, a 1000-line review in 5 minutes.
• Explain the Why. The description of a review is not used to say what has been changed (the code already does) but the intent behind the change.
• Be explicit. The proofreader likes to know what to expect. There is nothing more frustrating than a request for a review called “Fixed” (the plural also indicates that the review is not atomic).
• Do a self-review before assigning it, this helps to reduce the feedback related to forgotten debug messages, commented code… feel free to comment on some aspects of the code to give context to the reviewer.
• Comply with standards. Your reflector will thank you for reviewing a code with a familiar structure. It also allows him to focus on the substance rather than the form.
• Be responsible. The proofreading of your code does not absolve you of its quality, you are always responsible for it.
• As a proofreader
• Don’t look for the little beast, but aim above all at improving the structure of the code;
• Focus on the content, or do like Google with a “content” and a “shape” proofreader;
• Encourage joint reflection rather than give ready-made solutions;
• Distinguish between suggestions and necessary changes, especially when deadlines are being reconciled
• The tools
• Creating a pull request on Github

If you do your source code control with Git, most collaboration tools (Github, Gitlab, Bitbucket…) offer by default a code review when creating Pull Request / Merge Request. There are other more independent tools, with different options, at different prices.

To conclude

Even if at first sight the implementation of code review may seem like a cost, the return on investment is not negligible, both for the quality of the code and for the level of the team.

THE COST OF QUALITY ASSURANCE IN WEB DEVELOPMENT

Have you ever laid tiles before?

It’s an activity I really enjoy. Like development, it is both very mathematical and requires a certain amount of creativity.

And I never lay tiles alone. Not because I can’t do it, it’s not complicated. The surfaces are glued, a tile is laid, then the next one, and so on, row after row. It’s a job you can easily imagine. If we had to make an analogy with development, it would correspond to the writing of the code.

The invisible work behind code writing

But behind these representations of the task, there is a whole work that is less easily imagined: a kind of “invisible work”. This takes into account, for example, the measurements of the part, the drawing of the plan, the choice of the right tools, the right glue, the preparation of the surfaces, the cleaning… I can go on, but almost all of them find their analogy in the life of an IT project.

Invisible work” is quality assurance

I told you I never lay tiles alone. I usually do it with my father, and we have a well-oiled process (for amateurs).