2022年9月9日 / 最終更新日時 : 2022年9月12日 user 事例・ソリューション

コミットレビューを成功させる方法

ほとんどの開発チームや DevOps チームは、チェックインレビューがワークフローの必要な部分であると認識しています。しかし、これらのコミットレビューへのアプローチを誤ると、必要以上に難しく、時間がかかり、報われないものになってしまうかもしれません。

ここでは、コミットレビューがチームにとって実りあるものとなるよう、実践いただきたい 5 つのアイデアをご紹介します。

継続的なテストを可能にする

レビュアーは、レビューが退屈でつまらないと感じていませんか ? おそらく彼らは、レビューのルーティン化した側面に過剰な時間を費やさなければいけないことに嫌気をさしているのでしょう。たとえば、レビュアーに新しいコードのテストを十分にさせるために、誰かが労力を費やす必要はありますか? この問題には解決策があります。それは継続的テスト (CT) です。

ポリシーとツールを組み合わせて、すべてのレビューに独自のビルトインテストを導入し、CT プラットフォーム自体がそれを実行・表示するようにします。そうすることで、すべてのレビューが、すでに完了しているルーティンテストから開始されます。ルーティン化が難しいテストが一部あっても問題はありません。よくできたテストがあれば、レビュアーはこのようなルーティン化が難しいテストに集中し、通常の回帰テストはすべてCTにまかせることができます。その結果、より信憑性の高いテストができ、退屈もしなくなります。

チェックを自動化する

この方法で自動化できるのは、従来の単体テストだけではありません。あなたのチームでは、コードの記述にあたり、タブキーの使用方針や、改行コードの混在（Unix スタイルのLF、DOS スタイルの CRLF）といった問題は発生していませんか？このような異常の検出を、エラーを起こしやすい人間に依存してはいけません。これらの文体チェックを自動的に検証する十数行のスクリプトを作成しましょう。

括弧の使い方は適切か？未使用の変数はすべて削除されているか？色の値は承認されたパレットから選ばれているか？レビュアーに敬遠されるようなこのような事柄はすべてスクリプトによる自動検出の候補となります。

小さな単位に分ける

レビュアーは、レビューすることに疲弊していませんか ? レビューの単位をより小さく分け、レビュー数を増やしてみてはいかがでしょう。

ここで例を挙げてみましょう。単一の機能要件には、新機能のための「場所を作る」ために、複数の異なる実装手順が含まれる可能性があります。新しいテスト、リファクタリングされたクラス定義、更新されたユーザーインターフェイスレイアウト、いくつかの関数名の変更などです。ビジネスアナリストには 1 つの機能強化にしか見えないものに、13 個のソースファイルにまたがって 200 行近いソースコードが含まれています。これをレビューするのは大変なことです。

しかし、このコミットが 5 回のコミットとして書き直されたとします。最初の 3 回は機能の変更はありません。実際の機能拡張のためにより良い基盤を作るための単なるリファクタリングに過ぎません。この例では、4 回目と 5 回目のコミットは新しい機能の実装とテストにのみ焦点を当てており、既存のアプリケーションが行うすべての動作から明確に分離されています。この時点では、5 回の各コミットには 50 行以下のソースの変更 (わずか 2 画面分) しか含まれておらず、理解しやすい状態です。5 回の小さなレビューは、元の 1 つの大きなレビューよりも消化しやすくなります。

このようにレビューをより小さな単位に分解することは、慣れが必要ですが、その努力は報われます。目標は、レビュアーがコミットの正しさをはっきりと即座に理解できるように、各レビューを分かりやすくすることです。

また、このような小さなステップを踏むことで、混乱を発見しやすくなります。要件を誤解していても、小さなレビューをいくつも書く優れた技術が実装者にある場合、その誤解は一般的にレビューの少数にしか影響を与えません。その少数の混乱した小さなコミットがより簡単に修正される一方、大多数の正しく小さなコミットはそのまま変更なしでレビューと承認を受けることができます。

最終的には、各レビューをスキャンして高いレベルで把握するのに数分しかかからなくなり、少なくとも一日に 2、3 回は実践できるようになるはずです。たとえコミットが深く、完全に理解するのに何時間もかかるかかる場合でも、実装の背後にある本当のアイデアを見えにくくする、名前の変更・パッケージング・その他の維持管理作業、といった要素を切り離して見ることができるようにすべきです。

これと対照的なのが、コミットが大きすぎるためにレビュアーが難色を示して締め切りまで後回しにするという、よくあり過ぎるアンチパターンです。このような姿勢と範囲の組み合わせは、すべての人を失敗に陥れることになります。

非同期にする

レビューを容易にするもう 1 つの側面は、固定されたスケジュールからレビューを解放することです。開発の世界では、リモートワーク化が進んでいるため、レビュアーは、レビューの大半のスケジュールを自分で決められるようにしましょう。

特に、小さな単位でのコミットでは、全員が同じ時間に同じ場所でレビューすることにメリットはありません。その代わり、迅速かつ便利にレビューを処理できるように、レビュアーを訓練しましょう。

競合を解決する

最良の結果を得るためには、競合のないレビューリクエストを送信してください。

「開発者がある実装を始め、良い形に仕上げ、提案されたブランチ、コミット、リクエスト (ローカルのワークフローによる) を送信し、レビューを受け取り始める。そしてその時に初めて、そのコミットが現在のヘッド、マスター、または権限で競合していることに気づく。」・・・これは、一部のチームではよくある状況です。

このような競合が発生したら、皆の余分な作業を省き、すぐに解決するようにしましょう。承認を得てから競合を解決し、競合の解決の再レビューが必要になるという方法は、余計な作業を増やすだけです。レビュアーが競合のないリクエストを確認できるように解決してください。

ほとんどのバージョン管理、継続的インテグレーション (CI)、またはソース管理システムは、競合を検出するように設定できます。このような設定で、競合のないリクエストを維持して、レビュアーのために良い状態に保つように取り組むことが大事です。