コードレビューしてますか？開発だけで忙しいのにいつコードレビューしますか？スピーディーに変化する世界で複雑なコードレビューツールの使い方とレビューポリシーを開発者に周知し、開発flowに合わせたレビューをすることが可能でしょうか。よく使われているコードレビューツールの紹介とGitHubで簡単にコードレビューする方法をモバイルデータベースRealmの事例を挙げて説明します。

私のコードレビューの記憶

私もコードレビューをしていました。大企業でのことです。

1. コードレビューミーティング設定
2. レビューを受けるコードの範囲や会議室、時間などを共有
3. 開発者らは事前にコードを読んできた後、会議室でコードレビュー

このように行われていたのですが、予想通りうまくいきませんでした。みんな忙しいのでコードレビューミーティングを設定しない上に、会議の前にコードを読んできたこともないです。1時間という短い会議時間中に開発者がコードを説明するのに時間をかければ、会議に出席した開発者たちの目に見えるのは追加的な疑問事項とコードコンベンションだけでしょう。結局は会議に出席した5人以上の開発者らは時間も浪費して得ることはない不幸な状況になります。😂

コードレビューツール

そこで登場したのがコードレビューツールです。上で例を示したコードレビューを一箇所に集まってする同期(synced)コードレビューとすると、コードレビューツールを使用すれば非同期(async)的なコードレビューを進めることができます。ツールを使用することでコードのリポジトリに触れず、コードにコメントのをつけて会話をつないでいくことができます。これを助けてくれる道具はGerrit、Review Board、Phabricator のようなオープンソース無料ツールがあります。もう少し予算をかけられる会社のためにはJetBrainsのUpsourceや、AtlassianのCrucibleのようなツールもあります。これらは内部LDAPと連動してJIRAのようなIssueトラッカーとの統合を通じて内部にある多様な構成管理ツール(Git、SVN)の中にあるコードをレビューすることを手助けしてくれます。下はUpsourceのホームページにある画面例です。

このようなツールは大きい会社でコードレビューを組織的に管理するには良いのですが、多様な外部モジュールと連動して環境を設定するのに多くの努力が必要で、管理するにも多くのノウハウが必要です。もちろん有料ソリューションなので別途費用がかかることもデメリットです。

GitHubのPull Requestを使ったコードレビュー

多くの人がPull Requestをオープンソースに貢献するための手段だと思っていますが、GitHubのPull Requestは立派なコードレビューツールです。多くの人がgit flowというgitのブランチ管理戦略について聞いたことがあると思います。たくさんのツールがgit flowを支援していますが、かなり複雑な方法なためチーム内で定着するには多くの時間がかかります。GitHubではこれよりはるかに単純なGitHub Flowというブランチ戦略を紹介していますが、その核心はコードを正しくコミットしたり、masterに直接マージせずにPull Requestを投げてそれをレビューして議論した後にマージすることです。また、GitHubではコードレビュー機能を自分たちの中核機能のうち一つだと紹介しています。

Pull Requestを使うことで他のメンバーに@mentionでコードレビューを依頼して、他のメンバーは該当コードがあるブランチに切り替えて直接見るのはもちろん、行ごとにコメントで修正を依頼したり、意図を聞くことができます。トリガーを設定することでCIで自動的にテストされるようにすることもできます。

それではモバイルデータベースを開発するRealmではどのようにコードレビューをしているのか見てみましょう。

isEmptyという機能を追加するPull Requestの例を見てみます。上リンクはすでにmergeされているので多くの議論が「outdated diff」という名前で畳まれています。これはクリックすることで見ることができます。

まず下記のようにコードについて質問し、回答し、議論します。インターフェースはフェイスブックのコメントに似てい���簡単です。

CI上ですべてのテストをパスし、2人以上のレビューアからレビューOKが出ると、mergeすることになります。それまではずっと議論をしながら修正していくことになります。

Pull RequestはGitの機能ではなく、GitHubの機能なのでPull Requestを使ったコードレビューはGitHubやGitHub Enterpriseを使用する場合にのみ可能です。もちろん、Bitbucketでも同様の機能を提供しているのでBitbucketでもPull Requestを使用することができます。GitHubを使ったコードレビューはGitHubを使ってさえいれば、他に設定や追加コストなしですぐに適用することができます。

GitHubが説明しているPull Requestに対する紹介リンクも確認してみてください。

すべてのコードをコードレビューしなければならないか?

いえ、そうではないはずです。例えばマーケティングチームが要求するタイミングが重要なUI変更や、プロジェクトを一人で担当する場合(会社でAndroid開発を一人でする場合)には、このようなツールを使ったコードレビューは合わないことがあります。RealmでもProductに使用されているすべてのコードはコードレビューのフローを通りますが、他のリポジトリにある社内ツールや、重要でないリポジトリ(ホームページやサンプルコードなど)の場合、レビューが必要なのかを判断して必要であればPull Requestのフローを通ることになります。ビジネスロジックや、複数人が一つのプロジェクトを一緒に開発するプロジェクトの場合には、コードレビューを通じて他人が開発したコードと一緒に動作によって生じかねない問題を未然に防いでコードの完成度を高めることができます。

すべてのコードをレビューしなければならないとか完璧なコードレビューをしなければならないということに強迫観念を持つ必要はなく、GitHubのようなツールを使用して一つずつ導入していくのはどうでしょうか?

コードレビューは文化である。開発者の権利である

適切なコードレビューは開発者の権利です。人のコードをレビューし、討論することは何よりも立派なプログラミング能力を育てる方法です。また、「レビューを受けるコードである」と意識しながらコーディングするようになると、可読性やロジックなどをよりきれいにコーディングすることになります。コードレビューはシステムに強制されるより、製品と人を優先視する文化をもとにしなければなりません。決して導入は簡単ではありませんが努力してみるべきです。英会話支援プログラムや他の福利厚生より、コードレビューできるシステムと文化を要求してください。会社のために、開発者自身のために。 —————————————————————————————-

Realmは、モバイルデータベースです:SQLiteまたはCore Dataの代替として使用することができます。さらに知る