コードレビューはもっと良くできる

• 開発者たちは GitHub の コードレビュー体験 に多くの不満を抱えており、それを改善するための新しい試みが行われている
• git-review という実験的なツールは、コードレビューを ブラウザの Web インターフェース ではなく、ローカルでコードと一緒に直接扱えるよう設計されている
• レビューは 単一コミット で管理され、コード内に注釈のようにレビューコメントを残し、レビュアーと作成者がそのコミットを一緒に修正していく方式
• しかしレビューの途中でコードが修正されたりリベースされたりすると、競合処理 や --force-with-lease の利用などで不便が生じ、大きな成功には至らなかった
• 結局は Web ベースのレビューに戻ったが、レビュー状態を Git リポジトリに直接含めるという発想は依然として魅力的であり、Gerrit-style Change-Id の導入など今後の Git 改善とともに、より良い代替案が登場する可能性がある

---

コードレビューシステムに対する問題意識

• 現在、多くの人が GitHub のコードレビュープロセス に不満を持っている
• 主な問題は スタックされたプルリクエスト や interdiff レビュー へのサポート不足に加え、
  • レビュー状態がリポジトリ内部に保存されない
  • リモート優先の Web インターフェース でのレビューが必須である
• 私が問題だと感じているのは、レビューの非中央集権性の不足 と インターフェースの非効率性 である

コード作成とレビューのワークフロー比較

• 人々はコードを書くとき、ローカルで エディタ を使う
  • メモリや NVMe のレイテンシが少なく、ユーザー独自のワークフローに最適化された環境である
• コードレビューも ソースブランチをローカルに pull して作業する方式が好ましい
  • Magit のようなツールを使えば、diff だけでなくコード全体のコンテキストも探索できる
  • テスト実行、コード定義への移動、リファクタリングの試行など、強力な開発環境 を活用できる
• 一方で、PR に フィードバックを残すにはブラウザ で遅い Web インターフェースへ移動しなければならず、大きな diff では入力遅延もひどい

理想的なコードレビューインターフェースと保存構造

• 実際には、コードにインラインでコメント を残したり、直接コードを修正したりするのが最も自然である

  // CR(matklad): Hm, this check seems imprecise to me.  
  // Shouldn't we compare `replica.view` instead of `header.view` here?  
  if (header.view != view) return;  
  

• データがローカルの git リポジトリではなく リモート DB に保存されることで、レイテンシ や ベンダーロックイン の問題も生じる

git-review のアイデアと実際の経験

• git-review のアイデアは次のとおりである:
  • コードレビューは PR ブランチ先頭の 単一コミット で行われる
  • そのコミットに 特別なマーカー付きのコードコメント が追加される
  • レビュアーと作成者がそのコミットを交互に修正しながら、push --force-with-lease に基づくコラボレーションを行う
  • すべてのコメントが 解決済み表示 (//? resolved) になり、レビュー終了時には revert コミット を追加して記録を残す
• アイデアは単純で実用的だが、実際には次のような問題が発生した
  • レビュー中のコード修正 時に、下位コミットや新規コミットでコメントとの競合が頻発する
  • force-push の過程で共同作業の摩擦が生じ、作業の複雑さが増す
  • コードの変更履歴とレビュー進行の 不整合、およびマージ競合の管理が難しくなる

新しい変化と今後の可能性

• 今後、Git upstream に Gerrit スタイルの Change-Id が導入される可能性がある
  • コミットごとの修正履歴追跡が容易になり、interdiff レビュー のサポート拡大が見込まれる
  • ただし git-review 方式とは一部で衝突が予想される
  • 新しい Change-Id 構造では、コミット自体にレビューコメントを追加 するなどの新しいアプローチも可能になるかもしれない

結論と参考になるシステムの紹介

• 結局、現時点では Web インターフェースベースのコードレビュー に戻っている
• より良いソリューションの必要性は依然として残っている
• 参考になる関連システムやツール
  • Fossil: すべての情報をリポジトリ内部に保持する SCM システム
  • NoteDb: Gerrit のレビュー状態保存履歴を git に統合
  • git-bug: issue 情報を git に保存
  • git-appraise: レビュー情報を git 自体に保存
  • prr: エディタ内で GitHub API と連携してレビューインターフェースを実装
  • How Jane Street Does Code Review: より良い現実例の紹介
  • git-pr: PR ワークフロー全体を git のネイティブ機能で置き換えるプロジェクト

まとめ

• まだ完璧な解決策はなく、より良い開発者体験 に向けた試みが続いている
• 今後の発展に大きな期待が寄せられている