前回はイテレーション的ソフトウェア開発が重要である理由について紹介しました。今回は、コードレビューの観点からイテレーションの重要性について考えてみます。
GitLabでは、反復を可能な限り小さくして可能な限り迅速に成果を出すようにと定義しています。マージリクエストにおいて、もし推奨する指針を1つだけ挙げるとしたら、それは「反復」です。本質的に、ソフトウェアは反復がすべてです。ソフトウェアとは大きな問題を細かく分解し、より取り扱いやすい問題にするものです。他のスキルと同様に、反復について学び、改善するように実践を重ねていきます。あなたが次に「Submit merge request」ボタンをクリックするとき、一瞬立ち止まり、これからサブミットしようとするマージがより小さくできないか考えるようにしてください。
なぜ小さなマージリクエストがいいのか
長いマージリクエストを書くことよりも悪いことは、長いマージリクエストを確認することだけです。これは、反復（ひいては小さなマージリクエスト）が私たちが推進する価値の1つである理由です。
それゆえに私たちは特定のサイズを超えるマージリクエストがあれば、コード作成者に分解するように求める「DangerBot」を作成したほどです。
巨大なマージリクエストは複雑さを増やすだけではなく、コードレビュアーに技術的な問題を引き起こす可能性があります。レビューが特定の行数を超えると、ブランチをチェックアウトし、プロジェクトを起動し、スモークテストなしに判断することが明らかに難しくなります。複雑なレビューのスモークテストはいいアイデアではありますが、こうしたプロセスをコードレビューで習慣化するべきではありません。大きなマージリクエストはマージの競合、コンテンツの腐敗、その他の問題を生じさせるかもしれないからです。
GitLabの監視担当のバックエンドエンジニアであるサラ・ヤソニク（Sarah Yasonik）は、レビュアーがあまりに大きく、あまりに複雑なマージリクエストを扱う際には、新規の小さなマージリクエストを作成することで、コードの塊をレビューするするように推奨しました。すでに巨大化したマージリクエストにコードを追加し続けるよりも、大きすぎるマージリクエストを分割したほうがましです。
フォローアップの技巧
コードの作成者およびレビュアーは、従うべきいくつかのベストプラクティスがあります。もしもあなたがコードの作成者で、フォローアップレビューを提供する際には、常にその約束を実行するように心がけてください。
- もしあなたがコードレビュアーであれば、これら4つの要素がヒントになるでしょう。
- コードの作成者にフォローアップ依頼する権限があると考える
- フォローアップの申し出を快く受け入れる
- コードの作成者には忍耐強く
- フォローアップの申し出をリジェクトする最善のタイミングを知る
コードレビューで反復を使用するための実用的なヒント
なぜ反復が重要になるのか
マージリクエストが小さいほど、コードレビュアーがチェックしやすくなります。小さな変更でリリースするという発想は私たちが掲げる反復の価値と一致しています。かつてGitLabに在籍していたフロントエンドエンジニアリングのマネージャーであるクレメント・ホー（Clement Ho）は反復で主要なチャンピオンでした。彼がどのようにマージリクエストを小さな単位に分解するかについて、私が注意を向けるようになると、ほぼすぐに反復のメリットに気づくようになりました。
反復はGitLabではとても重要であるため、CEO シド・シブランディ（Sid Sijbrandij）は大きなプロジェクトの分解に専念するための時間を週次で開催しており、メンバーの反復についての競争力を評価しています。
小さなマージリクエストがレビュアーにどのように役立つか
反復が小さなマージリクエストで最小限の実行可能な変更（MVC）をリリースすることとするなら、反復を完全に受容するエンジニアは、レビュアーを楽にするためにマージリクエストでリリースするコードを少なくします。
実際、私たちはそうしてきました。私たちはマージリクエストのレビュアーとしてアサインされたとします。あなたが快適に過ごそうと思った矢先、マージリクエストを開いたら複数のファイルに渡る1,000行を超えるコードを目にすることがあるかもしれません。マグカップにコーヒーを注ぎ、疲れるレビュープロセスに向けて準備しなくてはなりません。
大きなマージリクエストに関わる問題はセルフレビューを実践したことがあるか、このような状況に陥ったことがある場合は明確です。大きなマージリクエストが大きな問題の兆候になる理由には次のようなものがあります。
- マージリクエストが長いほど、コード行数が多くなる
- 不安定な接続の可能性が高くなる
- ソリューションや機能のパスをたどるのが難しくなる
- いとも簡単にバグを見逃す
- 作者はたくさんのコメントを見て、心が折れる
シンプルな考えですが、過小評価されています。次の理由により、マージリクエストを小さくするように心がけてください。
- 読むコードを少なくする
- 異なるコンテキストはそれぞれのマージリクエストに分ける
- レビュアーがより簡単にコードを追える
- 機能開発の履歴を追うことが簡単にする
- マージリクエストごとのレビューコメントが少ないほど、コード作成者のモチベーション維持には良い
最終的には、すべてのリリースが私たちのお客様に新しい価値をもたらすことを保証したいので、私たちはコードを注意深くレビューします。
