Popular posts

We do not have any formal tools or processes for code review, but they are a natural part of our culture. All commits are reviewed, most of the time by several people.

There are always a lot of different projects going on internally at Algolia, from the core engine to the public API clients. All projects follow mostly the same flexible process: we use feature branches off our master branch in git that are then merged back into master after a Pull Request. This Pull Request allows us to do some code review asynchronously.

All commits are public, so anyone can review them. We usually wait for at least one collaborator to comment with a “LGTM” (Looks Good To Me) before merging. If some code is unclear or could be improved, we leave comments (directly in GitHub) until the PR is ok. This allows each of us a chance to have a look at the integrated code and learn/ask questions before it gets merged.

To keep the human verifications to a minimum, we heavily rely on automated tools (linters, unit tests) and run them automatically through TravisCI on each PR. If the automated build fails, we usually do not even bother to check the code and just wait for the commiter to fix it. Only once the automated tests pass do we start checking the actual code.

We also heavily use Slack internally to discuss all possible matters. We have GitHub integrations into specific channels that let us know when new commit/PR/comments are added. We’re not doing much pair programming today in terms of code review, and this is something we’d like to do more in the future. Because we have a team distributed between Paris and SF, it is always better to be able to do things asynchronously.