We have already mentioned the lean startup approaches in business and Agile methodology, both focused on testing (either the hypothesis offered or the code written). And while quality assurance usually means checking if the compiled product or service fits the acceptance criteria, functions properly and allows reproducing the previously designed use cases, the software development process also include the code review procedure. Let’s pay a bit more attention to it.
While the work of designers, marketers and project managers is rarely checked by other colleagues, the work of developers requires constant mental efforts, which makes it impossible to bring the flawless result. So how to find and fix those small mistakes in the code in the most efficient way? This is where code review appears to be more effective that the work of the quality assurance teams.
The 'code review' process gathers fellow developers and sometimes QA specialists, who together use predefined approaches to read the code line by line and then check it for flaws, adherence to coding and commenting standards and consistency with the overall program design.
Having code review strictly defined as a part of daily programming workflow brings a few benefits to the team.
1. Found in the code, mistakes like mistypes, security bugs, architectural errors and business logic flaws are much easier and quicker to be fixed than if found by QAs in the product already compiled. So code review saves a lot of time and, eventually, money, especially if otherwise the bugs would be found only after the product went public.
2. Code review is a form of communication between developers and thus a great way to help both junior developers quickly raise their proficiency through learning their trouble spots and senior developers find common mistakes.
3. When a reviewer learns the code written by someone else, he gets to know the product better. Thus, when it comes to making new decisions on the development process, there are at least two specialists who: perfectly know how the product has been written; can easily communicate to each other; able to find and discuss the best possible solution for the current problem.
4. If a developer knows his work will be reviewed, it simply means he is more motivated to write the flawless code and will put more efforts to that. That makes both the developers and the code reviewers more professional, since both of them will strive to achieve better results in their work.
We at RubyGarage perform code review through GitHub, and you can read the corresponding post about GitHub if you want to learn more. It is indeed an extremely helpful tool, as it frees us from an unnecessary email communication, manual issue tracking and so on.
Finally, earlier we mentioned coding standards as a necessary thing to check when reviewing the developer’s work. Apart from the general standards that make the code readable for any developer, the additional standards can be applied to make not only the review, but the code itself easier to process.
It may be limitations on the text line length, review time, acceptable defect rates and so on. The idea here is everything that you analyze and measure gets better over time, so constant code review makes the development process not only efficient in the long-term perspective, but also more predictable and allowing to be estimated.
Although code review was first invented in 1970’s, when Michael Fagan mentioned it in his paper, more and more attention is paid to this development aspect nowadays. This is because of our reality, where software production schedules accelerate each year and product deployment is now an endless process. So if you want to create a great web product, pay attention to the code review process in your team.