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

第3回 より思慮深いコードレビューを書くためには

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

フィードバックは私たちにとってソフトウェア本体同様に,個人的にも業務的にも重要です。GitLabではフィードバックのすべてではないにしても,ほとんどのコードレビューを使うことで相互に交換します。コードレビューに関してなら,ツールベルトに追加できるツールをいくつか共有しています。今回は,コード作者とレビュアーのためのコミュニケーション戦略について紹介します。

覚えておくこと:セルフレビューで詳細は重要です

GitLabにおいて,コードの責任はマージリクエスト作者にあります。コード作者はレビューを依頼する前にチェックリストを作成して,細部を確認することをおすすめします。マージリクエストのチェックリストの例を示します。

すべてのフィードバックサイクルの前に:
  • すべての行を読み返す
  • コードをローカルでテストする
  • すべての変更(またはできる限り)のためのテストを書く
  • マージリクエストに明確な説明を記述し,各フィードバックサイクル後に更新する
  • 変更ごとに少なくとも1つ以上のスクリーンショットを含める(多いほどいい)
  • ラベルを確認し,再確認する。その後に再び確認する
  • Monitor:Healthチームが実施しているように,事前にIssueに対して~"workflow::refinement"ラベルを使うことを検討する。チームはラベル機能を使って,Issue,マージリクエスト,エピックに互いに排他的なラベルで注釈を付けることができる。これにより,特定のラベルが一緒に使用されないようにすることで,より複雑なワークフローを実現できる。Scoped labelについてはこちらのドキュメントを参照
  • レビュアーであるかのようにコードをレビューする。積極的に,出そうな質問に答えておく,フォローアップのIssueを事前に開く
  • アクションにある最後の最重要な部分を確認するなら,フロントエンド保守のNatalia Tepluhinaの方法を参照する。マージリクエストでレビューアに質問されるであろうことを事前に回答している

誠意を持ちコミュニケーションする

コードレビューを正しく行う上で最も難しいことの1つは,人間味を伝えることです。フィードバックを交換する時,人間の習性として,フィードバックの最も否定的な側面をデフォルトにすることで,認知の歪みを引き出す可能性があります。GitLabでは私たちの価値観に組み込むことで,善意を引き出すことの重要性を強調しています。

従来型のコメントシステムがコードレビューにどのように貢献するか

より効果的なフィードバックを与えるために,従来型コメントシステムを試してみてください。従来型のコメントシステムでは,マージリクエストのレビュー担当者と作者に役立つ方法でコメントを書くように呼びかけています。

従来型コメントシステムはコメントの意図とトーンが分かるように,目を引く一語でコメントを開始するように呼びかけています。この手法により,読者はコメントがどんな立場で発せられているのか理解する機会を得ます。

実験してみましょう。レビューのためにコードをサブミットした時,どちらのコメントを読みたいと思いますか?

  • 例1:代わりに,Xについてどう思いますか?
  • 例2:[suggestion (non-blocking)] 代わりに,Xについてどう思いますか?

恐らく例2を選んだのではないでしょうか。命令や必須の変更としてのコメントではなく,別のアプローチを試すための提案として,コンテキストがあり,共感を持ちコミュニケーションしながら構成されているからです。

このコメントで魔法となるのが冒頭の「suggestion (non-blocking)」です。コメントを読む前に,即座に,以下の最も重要なポイントが分かります。

  • レビュアーからの提案であること
  • 「non-blocking⁠⁠,コードの安定性に必要で難しい変更というよりは,親近感をこめた提案であること

こうしたスタイルのコメントのもう1つの利点は,マージリクエストの作者にとって,レビュアーが自分の作業をブロックしていないことを理解できることです。⁠blocking」「non-blocking」をハイライトすることで,マージ作者はレビュアーが伝えようとしているコンテキストを完全に理解できます。

例えばマージリクエストをコミットすると,レビューには8つのコメントが返されたとします。例1だと,コメントにコンテキストがありません。すべてのコメントはブロッカーとしてカウントされるものかそうでないものか,そうしたコンテキストがないため同等に扱われます。例2だと,従来のコメントシステムを使用してコメントにコンテキスト化します。コメントを優先順位で扱うことができます。

  • ブロッカー:ライン上でマージを取得するために必要なもの
  • 非ブロッカー:別途のマージリクエストとなりうるもの,または議論のきっかけとなるもの

今度コードをレビューするときには,従来型コメントアプローチを試してみてください。それによりマージリクエスト作者がレビューに返答する方法にどのように影響するか,レビュアーとなるあなたがレビューを離れる時の感情にも関心を持ってみてください。

著者プロフィール

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

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

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


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

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

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