Code Reviews


We always use source code control. It's like a time machine. We can work in parallel universes of our source code, experimenting without fear of losing work, rolling back if something goes wrong.

Git is a source code control system written by Linus Torvalds. It's fast and great for working in branches.

We use Gitlab for hosting our Git repositories, where each project's repository has features branches used for development, a staging branch and a master branch used for production.

Here's the flow:

  1. Create a local feature branch.

  2. The branch name should follow this pattern: <name-of-task>, e.g. add-login-system.

  3. Increment for that feature should be committed and pushed in a daily base to keep a fresh copy in the repository.

  4. Write a good commit message: Understanding why something happened months or years ago should be possible and efficient; A commit message merits a bit of explanation and context; Explain the why and not the how. We use commitlint to verify the commit message structure.

  5. When a feature is completed, and tests pass, commit the changes.

  6. Submit a Gitlab merge request.

  7. A team member other than the author reviews the merge request.

  8. They make comments and ask questions directly on the merge request.

  9. When satisfied, they approve the merge request that it's ready to merge with staging branch.

  10. The merge process will delete the remote feature branch and start the Continuous Integration process.

Automated Acceptance tests move code failure earlier in the development process. It's better to have a failing test on your development machine than in production. It also allows you to have tighter feedback cycles.

Code reviews that happen right before code goes into master offer similar benefits:

  • The whole team learns about the new code as it is written.

  • Mistakes are caught earlier.

  • Coding standards are more likely to be established, discussed, and followed.

  • Feedback from this style of code review is far more likely to be applied.

  • No one forgets context ("Why did we write this?") since it's fresh in the author's mind.

Our experienced designers & developers can help.

In person, small teams, focused sprints. 5 years & 50+ successful clients.