細分化とコードレビュー見直しによるイテレーション的ソフトウェア開発のメリット

第2回 小さなマージリクエストが優れたレビューの鍵となる理由

この記事を読むのに必要な時間:およそ 1.5 分

前回はイテレーション的ソフトウェア開発が重要である理由について紹介しました。今回は,コードレビューの観点からイテレーションの重要性について考えてみます。

GitLabでは,反復を可能な限り小さくして可能な限り迅速に成果を出すようにと定義しています。マージリクエストにおいて,もし推奨する指針を1つだけ挙げるとしたら,それは「反復」です。本質的に,ソフトウェアは反復がすべてです。ソフトウェアとは大きな問題を細かく分解し,より取り扱いやすい問題にするものです。他のスキルと同様に,反復について学び,改善するように実践を重ねていきます。あなたが次に「Submit merge request」ボタンをクリックするとき,一瞬立ち止まり,これからサブミットしようとするマージがより小さくできないか考えるようにしてください。

なぜ小さなマージリクエストがいいのか

長いマージリクエストを書くことよりも悪いことは,長いマージリクエストを確認することだけです。これは,反復(ひいては小さなマージリクエスト)が私たちが推進する価値の1つである理由です。

それゆえに私たちは特定のサイズを超えるマージリクエストがあれば,コード作成者に分解するように求める「DangerBot」を作成したほどです。

巨大なマージリクエストは複雑さを増やすだけではなく,コードレビュアーに技術的な問題を引き起こす可能性があります。レビューが特定の行数を超えると,ブランチをチェックアウトし,プロジェクトを起動し,スモークテストなしに判断することが明らかに難しくなります。複雑なレビューのスモークテストはいいアイデアではありますが,こうしたプロセスをコードレビューで習慣化するべきではありません。大きなマージリクエストはマージの競合,コンテンツの腐敗,その他の問題を生じさせるかもしれないからです。

GitLabの監視担当のバックエンドエンジニアであるサラ・ヤソニク(Sarah Yasonik)は,レビュアーがあまりに大きく,あまりに複雑なマージリクエストを扱う際には,新規の小さなマージリクエストを作成することで,コードの塊をレビューするするように推奨しました。すでに巨大化したマージリクエストにコードを追加し続けるよりも,大きすぎるマージリクエストを分割したほうがましです。

フォローアップの技巧

コードの作成者およびレビュアーは,従うべきいくつかのベストプラクティスがあります。もしもあなたがコードの作成者で,フォローアップレビューを提供する際には,常にその約束を実行するように心がけてください。

もしあなたがコードレビュアーであれば,これら4つの要素がヒントになるでしょう。
  • コードの作成者にフォローアップ依頼する権限があると考える
  • フォローアップの申し出を快く受け入れる
  • コードの作成者には忍耐強く
  • フォローアップの申し出をリジェクトする最善のタイミングを知る

コードレビューで反復を使用するための実用的なヒント

なぜ反復が重要になるのか

マージリクエストが小さいほど,コードレビュアーがチェックしやすくなります。小さな変更でリリースするという発想は私たちが掲げる反復の価値と一致しています。かつてGitLabに在籍していたフロントエンドエンジニアリングのマネージャーであるクレメント・ホー(Clement Ho)は反復で主要なチャンピオンでした。彼がどのようにマージリクエストを小さな単位に分解するかについて,私が注意を向けるようになると,ほぼすぐに反復のメリットに気づくようになりました。

反復はGitLabではとても重要であるため,CEO シド・シブランディ(Sid Sijbrandij)は大きなプロジェクトの分解に専念するための時間を週次で開催しており,メンバーの反復についての競争力を評価しています。

小さなマージリクエストがレビュアーにどのように役立つか

反復が小さなマージリクエストで最小限の実行可能な変更(MVC)をリリースすることとするなら,反復を完全に受容するエンジニアは,レビュアーを楽にするためにマージリクエストでリリースするコードを少なくします。

実際,私たちはそうしてきました。私たちはマージリクエストのレビュアーとしてアサインされたとします。あなたが快適に過ごそうと思った矢先,マージリクエストを開いたら複数のファイルに渡る1,000行を超えるコードを目にすることがあるかもしれません。マグカップにコーヒーを注ぎ,疲れるレビュープロセスに向けて準備しなくてはなりません。

大きなマージリクエストに関わる問題はセルフレビューを実践したことがあるか,このような状況に陥ったことがある場合は明確です。大きなマージリクエストが大きな問題の兆候になる理由には次のようなものがあります。

  • マージリクエストが長いほど,コード行数が多くなる
  • 不安定な接続の可能性が高くなる
  • ソリューションや機能のパスをたどるのが難しくなる
  • いとも簡単にバグを見逃す
  • 作者はたくさんのコメントを見て,心が折れる

シンプルな考えですが,過小評価されています。次の理由により,マージリクエストを小さくするように心がけてください。

  • 読むコードを少なくする
  • 異なるコンテキストはそれぞれのマージリクエストに分ける
  • レビュアーがより簡単にコードを追える
  • 機能開発の履歴を追うことが簡単にする
  • マージリクエストごとのレビューコメントが少ないほど,コード作成者のモチベーション維持には良い

最終的には,すべてのリリースが私たちのお客様に新しい価値をもたらすことを保証したいので,私たちはコードを注意深くレビューします。

著者プロフィール

David O'Regan(デビッド・オレガン)

GitLab エンジニアリングマネージャー

言語,コード,JavaScript,ソリューション,最適化,関数型プログラミング,数学に情熱を注ぐ。プログラミング以外では,人がなぜそのような行動をとるのかを理解し,どのように自分が手助けできるかを考えている。ウェブサイトをいじっていないときは,ジムに行ってストレスを発散している。


伊藤俊廷(いとうとしたか)

GitLab APAC/Japan シニアソリューションアーキテクト

日本のSIerでソフトウェア開発,プロジェクト管理,技術調査,海外勤務等の業務に従事し,自身でも新しい開発ツールの導入,組織の文化醸成の難しさを痛感した。その後,開発経験を活かし,アプリケーションセキュリティベンダーにて,セキュリティテストのソリューションを戦略顧客に導入する任務を担った。現在は,GitLab APAC/Japanのシニアソリューションアーキテクトとして,顧客のDevOpsでの成功に向けた課題解決を行う。