The Importance of Code Review

Author: Ryan Io

As software development projects get larger, code reviews becomes increasingly important to maintain quality in the product, especially staff scheduling software. Peer review is a step that ensures that the new code being submitted does not break existing functionality and the code follows standard guidelines. It is also a learning opportunity for the developer whose code is in review.

A reviewer will give constructive feedback on how the code can be improved and can positively influence how code is written in the future. The process of having code reviewed will also encourage developers to write code which can be easily explained, knowing that having to explain the code it is likely to happen during the review process. It also gives the developer submitting the code confidence when the code is approved that it will not break existing functionality.

Here are some general practices to try to employ while doing code reviews: Rather than only looking for syntax errors and such, a reviewer should also look for issues such as the readability of code, which includes the use of comments and clear function naming.

A developer should make the code as understandable as possible by using small, clear functions with proper naming. For complex pieces of code, if this is not possible, adding comments to code which is unclear will help with readability and longer term maintainability. As a reviewer, comments on the piece of code should state what needs to be changed and should explain why it needs to be changed.

To help reviewers out developers can use proper commit names which clearly explain what the code is doing rather than leaving short messages such as “fixed issue.” Links to information about the task will also help reviewers understand what the purpose of the code being submitted is.

As a developer having their code reviewed, comments posted during code reviews can sound aggressive, but it is important to understand that these comments are to ensure quality in the code and are never personal.