Code Review

Introduction

Code reviews play a vital role in our project's development lifecycle. They provide a quality assurance check as well as it enables developers an insight into the whole code base.

This document describes the practices we have decided to adopt when conducting code reviews. These practices are fluid and are guaranteed to change over time as the team learns how to work together. As such, this document describes the current state of the process and should you wish to change it, please discuss with the rest of the team and modify this document.

Code review in practice

Due to the nature of our workflow, code reviews are performed after a commit has been pushed to the dev branch. This means that you should request a code review by moving the task to Waiting For Review column before you mark a task as done (see our Definition of Done). Commit hashes should be added to the task comment. If there are many commits to one file the file should be also added to the comment.

Each team member should watch the Waiting For Review column and review its tasks. When a team member chooses a task for review, the task comment should be updated to include the reviewers name and the task should be assigned for the reviewer.

After all of the task's commits have been reviewed by someone the task can be moved to Done.

A few guidelines to a successful code review:

• Review fewer than 300 lines of code at a time
• Take your time
• Be specific about your improvement ideas
• Foster a positive code review culture
  • See each bug as an opportunity to learn something new
  • Use constructive criticism
  • Do not evaluate team members based on the number of defects found during code review

Github commit diff view can easily be used for code review purposes. It shows the changes in red and green and allows for commenting.