Code review

Reviewing each other’s code is an important part of our internal working process. Code reviews have two main advantages in our minds. The first is that it greatly reduces the number of bugs allowed to make it to our production code, thereby raising the quality of our product. The second is that it informs team members of changes that are happening to the codebase, which distributes the knowledge of the inner workings of our product.

We follow a certain process to ensure the quality of our code, which covers steps all the way from development to production deployment. This process contains the following steps:

• When working on a piece of code that introduces a new feature, a fix or a piece of data analysis, we simultaneously create automated tests. We create tests that are helpful in catching bugs early when introducing new code, and helpful in catching breaking changes when changing old code.
• After completing the code, we hand over our code to a colleague from within the same team to review. In practice this means that we request a review from our team members via Pull Requests on GitHub.
• The reviewer requests changes to the code, whenever he/she spots any bugs or potential for improvement. A Pull Request is only accepted when both the reviewer and the original author agrees that the code works as intended.
• After a successful Pull Request, the code is deployed to a Staging environment where we can do further testing. This environment mirrors the setup of our Production environment. Any other teams depending on the new code can test it here, and make requests for further changes if necessary.
• Only after testing in the Staging environment shows no bugs, do we deploy our code to the Production environment where it affects the product that our customers use.

We’re committed to following our review process for all code we write, both for the sake of our customers and our employees.