デフォルトでコードレビューは不要

この記事は、著者の許可を得て配信しています。
 No code reviews by default 

我々は信頼に基づくエンジニアリング文化を構築したことによって、コードレビューを必要とせず、信じられないほどの速さで作業を進めることができるようになりました。

Raycastには、コードレビューは不要です。エンジニアはメインブランチにプッシュし、必要だと思ったらレビューをリクエストします。この記事では、私たちがどのようにして信頼に基づいたエンジニアリング文化を構築し、信じられないほどの速さで仕事を進めることができるようになったかを紹介します。

はじめに

Petrと私がRaycastを立ち上げたとき、私たちは3ヶ月間、同じアパートで、真横に座って仕事をしていました。毎日、ユーザーが求める機能を作るようにできる限り早く対応しようとしていました。この時は、コードレビューを行わず、お互いを盲目的に信頼していました。技術的な質問があれば、その場で解決し、コードをメインブランチにコミットして、次の問題に取り組むということをしていました。

分散したチームを成長させ始めたとき、コードレビューを導入すべきかどうか自問しました。一般的には、パフォーマンスの高いエンジニアリングチームではプルリクエストがベストプラクティスであると言われています。しかし、私たちは自分たちの「プロセス」の信頼性、コラボレーション、そしてスピードに満足し、コードレビューは必要としないとしました。その代わりに、すべてのエンジニアは自分の変更をメインブランチにプッシュする権利を持っています。自分のコードを他の人に見てもらいたい場合は、レビューをリクエストすることができます。時には、変更がtrunkに反映された後にレビューが行われることもあります。

慣習よりも責任

ソース管理にはGitHubを使用していますが、これにはコードレビューのためのプルリクエスト（PR）という概念があります。通常、エンジニアはあるタスクに取り組み、その変更点をリポジトリに提案します。議論を重ねて変更の可能性が出てきたら、エンジニアはその変更をベースブランチにマージします。このモデルは、オープンソースでは非常に有効で、誰でもプロジェクトに貢献することができます。しかし、私たちのチームでは、いくつかの理由からこのモデルは実用的ではないと考えました。

• プルリクエストでは信頼が失われます。コードを変更するたびに提案し、誰かに承認してもらわなければならないというのは、高度な信頼関係のもとで運営されるべきチームにとっては心もとないものです。コードにおいて、共同作業するために効率的な方法があります。
• プルリクエストではバグを防ぐことはできません。コードをレビューするのは大変です！明らかな間違いを見つけることはできても、一貫した精査はできません。多くの問題は使い込んで初めて明らかになりますが、コードレビューではそうはいきません。私たちはユーザーからのフィードバックによる迅速なイテレーションに依存しています。
• プルリクエストは遅くなります。エンジニアにとってコードレビューの優先順位は高くありません。彼らはレビューキューを整理する時間を作らなければならないからです。実際には、PRは後回しにされます。エンジニアとしてはPRには時間を割きたくないのです。

私たちは全責任を負うということを重視しています。すべてのエンジニアがアイデア出しからメンテナンスまでを担っています。エンジニアは自由にメインブランチにプッシュできますし、必要と思われる場合にのみコードレビューをリクエストするなど、当社のエンジニアリング文化はこれを反映しています。

実際のところはどうなのでしょうか？

私たちの目標は、変更をできるだけ早くドッグフード化（自社製品を自分たちで使用してテストすること）することです。そのために、全員がメインブランチで作業を行います。こうすることで、他の人がすぐにテストできるような変更が次々と起こります。継続的インテグレーションでは、すべてのコミットをビルドしてテストします。さらに、毎晩、日中にコミットされたすべての変更を含む内部リリースを行います。各リリースは、チーム全体に自動的にインストールされます。そうすれば、新しく変わった所を24時間以内にテストすることができるのです。

内部リリースを毎日行うことで、バグや使い勝手の問題を解決するために多くのフィードバックを簡単に集めることができます。チームが機能の品質に満足していれば、その機能は次のパブリックリリースの一部としてリリースされます。さらにイテレーションが必要な場合は、機能フラグを使って内部に留めておきます。こうすれば隔週でアップデートをリリースしやすくなります。

補足：プロジェクトの履歴をより分かりやすくし、不要なマージコミットをなくすために、マージではなくリベースを使用しています。

コードレビューをリクエストする場合もあります。コードベースの新しい部分に触れる場合は、プルリクエストを作成します。そのような変更では、初めてのデータベースマイグレーション作業を追加することができます。誰もが本番環境で失敗したくないので、むしろダブルチェックを行うくらいです。新しいチームメンバーは、コードベースに慣れるために、最初の2、3週間はコードレビューをリクエストすることがよくあります。その後、彼らは自信を持ってより大きな変更を行えるようになるので、それからメインブランチに直接プッシュするようになります。

必ずしもPRである必要はありません。「ポストコミットメッセージ」でチームメイトに特定の変更を知らせるだけで十分な場合もあります。誰かが自分の変更をコミットした後、私たちのリポジトリを購読しているSlackチャンネルやGitHub自体のコミットに関連する人をリンクします。これは、他の人の作業に影響を与える可能性がある変更の場合に便利です。また、時差によるコードレビューの妨げを避けるためにも有効な方法です。複数のエンジニアの意見が必要な問題が発生した場合は、すぐにAroundでビデオ通話をして、画面を共有しながら共同作業を行います。コードベースの一部をリファクタリングしたり、お互いに影響を与えあう機能を調整したりするなど、より多くの人が関わる問題を解決するのに便利な方法です。

私たちは、この作業方法がより効果的であると考えています。長期間存続するブランチでの孤立した作業を避けることができ、アプリの継続的な更新によってより効果的になります。

独自のルールを作っておく

会社やチームで状況がそれぞれ違いますが、共通しているのは、最高の製品を最短で作りたいということです。ただそれを実現する方法は会社やチームによってさまざまです。私たちの場合は、自分たちのチームに賭け、すべてのエンジニアがベストを尽くせるように彼らを信頼することです。自分のコードを誰かにレビューしてもらうかどうかをエンジニアに任せることも彼らを信頼するということです。より厳しいセキュリティ要件を持つチームにとっては、これは適切なプロセスではないかもしれません。ただ今のところ、私たちはこの方法でうまくいっています。こうすることで、機能を迅速にイテレーションすることができ、大きな問題に取り組みたい優秀なエンジニアの興味を惹き、完全に分散したチームに適した非同期のコミュニケーション文化を確立することができます。

あなたのチームのルールを決めるのは、あなたとあなたの同僚たちです。ベストプラクティスを独断で採用することはありません。むしろ、他の人の状況が自分に当てはまるかどうかを自問してみてください。自分には当てはまらない場合が多く、より適した方法を見つけることができるのです。