4.3

4.3 コードチャーンとホットスポット分析

概要と動機

コードチャーンは、あるファイルやモジュールが時間とともにどれだけの頻度で変化するかを測定します。連続するコミットにわたって追加、修正、削除された行数です。それ単独では、チャーンはかなり弱い信号です。一部のファイルは、活発で健全な開発のもとにあるためによく変化し、一部のファイルは、放置されているからではなく安定していて正しいためにめったに変化しません。本トピックのアプローチの本当の診断の力は、チャーンを複雑さ(トピック4.1)と組み合わせることから来ます。頻繁に変更され、かつ高度に複雑なファイル、つまりホットスポットは、不均衡に欠陥の源になりやすく、チームの速度への足かせになりやすいものであり、実証研究は多くのコードベースと組織にわたって一貫してこれを裏づけています。

アダム・トーンヒルのソフトウェア分析学についての仕事によって広められたホットスポット分析は、そのターゲットを見つけるために手動の調査や主観的な判断をまったく必要としないため、特に価値があります。バージョン管理の履歴は、コードベース内のすべてのファイルについて、チャーンを計算するために必要なすべて、そして静的解析のツールと組み合わせれば複雑さも、すでに含んでいます。これにより、チームや組織は、逸話や振り返りでの最も声の大きい苦情ではなく本物の証拠をもって、コードベースのどの小さな部分が最初にリファクタリングの注意に値するかを正確に特定できます。

大規模なチームにとって、ホットスポット分析は本物の配分の問題を解決します。数十万行のコードベースは、どんなチームも包括的にリファクタリングする余裕があるよりもはるかに多くのコードを持っており、最悪の問題がどこに生きているかについての直感はしばしば間違っており、最近最も苦情を言った人や上級エンジニアがたまたま嫌っているファイルに偏っています。大規模で長寿命のコードベースを管理する企業や政府の組織は、本当に希少なリファクタリングの予算を最大の見返りを生み出すコードへと向けるために、このデータ駆動の優先順位づけに依存しています。

重要な原則

  • チャーンだけでは弱い信号だが、複雑さと組み合わせると強い信号になる。 どちらか一方の指標だけではなく、この組み合わせこそが本物のホットスポットを特定します。
  • ホットスポット分析は手動の調査をまったく必要としない。 バージョン管理の履歴は、それを自動的に計算するために必要なすべてをすでに含んでいます。
  • ホットスポットは優先順位づけの信号であり、自動的な判決ではない。 特定のホットスポットがどんな行動を正当化するかを決めるには、今も人間の判断が必要です。
  • 頻繁な変更は本質的に悪いことではない。 一部のチャーンは、品質の問題ではなく健全で活発な開発を反映しています。
  • この分析は、直感が失敗するまさにその場所で規模を拡大します。 どの個人も感覚だけで調査し優先順位づけするには大きすぎる大規模なコードベースにおいてです。

推奨事項

チャーンと複雑さを一緒に計算し、それらの組み合わせでランク付けする

意味のある期間、典型的には6か月から1年にわたって、バージョン管理の履歴からファイルごとの変更頻度を抽出し、同じファイルについて複雑さの測定(トピック4.1)と対にしてください。どちらか一方の指標だけではなく、一般的にはチャーンと複雑さの積である組み合わせによってファイルをランク付けしてください。なぜなら、根底にある研究が一貫して高い欠陥率と保守コストに関連づけているのはこの組み合わせだからです。

行動する前に人間の判断で上位のホットスポットを調査する

ランク付けされたホットスポットのリストは注意の候補を特定するものであり、自動的な行動リストではありません。あなたの上位のホットスポットそれぞれについて、人間の目で調査してください。これは本物に設計が悪くリファクタリングを必要とするコードなのか、それとも活発で進化するビジネスロジックの中心に位置するために正当に頻繁な変更を必要とするファイルなのか。後者の場合、優先事項は構造的な書き直しよりも、より良いテストやより明確な文書化かもしれません。これは、組み合わされたチャーン複雑さの信号にここで適用された、トピック4.1の本質的対偶有的複雑さの区別を反映しています。

インシデントと欠陥のデータに対してホットスポットを相互参照する

利用可能な場所では、特定したホットスポットが実際の本番インシデント(トピック6.2)や欠陥流出のデータ(トピック5.1)と相関しているかを確認してください。強い相関は、ホットスポット分析があなたの特定のコードベースにとって本物に予測的であることを検証し、それに行動するためのビジネスケースを強化します。弱い、あるいは存在しない相関は、データ品質の問題か、あるいはあなたの特定の文脈では、チャーンと複雑さが優先順位づけのための正しい信号の組み合わせではないことを示唆します。

単一の一時点ではなく、連続する分析にわたってホットスポットの傾向を追跡する

ホットスポット分析を定期的に(四半期ごとが一般的です)再実行し、以前に特定されたホットスポットが改善しているか、悪化しているか、解決されたか、そして新しいものが出現しているかを追跡してください。繰り返し旗を立てられたにもかかわらず複数の分析サイクルにわたって持続するホットスポットは、是正の努力が実際には適用されていないか、あるいは以前の是正の試みが本当の根底にある問題に対処していなかったことを示しています。

ホットスポットのデータをチームレベルの優先順位づけの会話に情報を与えるために使い、それに取って代わらせない

ホットスポット分析を、今最も重要なことについてのチーム自身の文脈的判断を上書きする自動的な命令としてではなく、優先順位づけの議論における証拠として提示してください。あるチームには、既知のホットスポットを一時的に優先度下げる良い正当な理由があるかもしれません(たとえば、近づいている計画された書き直しが段階的なリファクタリングを無駄な努力にするなど)。そしてその分析は、その会話に取って代わるのではなく、それに情報を与えるべきです。

トレードオフ:長所と短所

アプローチ長所短所
直感に基づく優先順位づけ速く、ツールが不要で、チームの文脈的知識を活用する最近性、個人的な好み、最も声の大きい苦情によって偏る
チャーンのみ計算が単純それ単独では弱い信号。頻繁な変更は本質的に悪いことではない
チャーンと複雑さの組み合わせ(ホットスポット分析)強く、証拠に基づき、既存のデータから自動的に得られる二つのデータ源を組み合わせ、判断で結果を解釈する必要がある
インシデントデータと相互参照されたホットスポット分析検証され、優先順位づけのための最も強い証拠信頼できるインシデントとコードの結びつけが必要で、すべての組織が持っているわけではない

中心にある緊張関係は証拠と文脈です。ホットスポット分析は、大規模で不慣れな、あるいは長寿命のコードベースの規模では直感に基づく優先順位づけが太刀打ちできない、客観的で規模拡大可能な証拠を提供しますが、あるホットスポットが今重要かどうか、あるいは重要でないかについてチームが持つ文脈的判断を欠いています。この緊張を解消するには、ホットスポット分析を優先順位づけの会話のための証拠基盤として扱い、タイミングとトレードオフについてのチーム自身の文脈的判断に取って代わるのではなく、それと組み合わせてください。

チームで話し合うべき問い

  1. チャーンと複雑さを組み合わせてランク付けした、私たちの上位5つのホットスポットは何で、そのランキングは私たちのチームの、私たちの最悪の問題がどこに生きているかについての直感と一致するでしょうか。 分析を実行し、データを見る前にあなたのチームが推測したであろうものとその結果を比較してください。食い違いはしばしば最も価値のある発見です。

  2. 私たちが特定したホットスポットは、実際の本番インシデントや欠陥流出のデータと相関しているでしょうか。 もしこれを確認するためのデータがあるなら、直接そうしてください。もしないなら、その隙間自体が、構築に向けて取り組む価値のあるものとして名指しする価値があります。

  3. 私たちの現在の上位のホットスポットについて、根底にある問題は、頻繁な変更を正当に必要とする本質的複雑さでしょうか、それともリファクタリングが本物に修正できる偶有的複雑さでしょうか。 どちらの答えも仮定するのではなく、一緒にファイルをたどり、この判断を明示的に行ってください。

  4. 以前に特定されたホットスポットは、旗を立てられたにもかかわらず複数の分析サイクルにわたって持続したことがあるでしょうか。 もしそうなら、なぜなのかを正直に調査してください。是正が実際には一度も試みられなかったのか、あるいは以前の試みが本当の根底にある原因に対処していなかったのかです。

  5. 私たちは現在、証拠に基づいてリファクタリングの仕事を優先順位づけているでしょうか。それとも最近あるいは最も声高に苦情を言った人に基づいているでしょうか。 あなたのチームの実際の現在の優先順位づけのプロセスについて、そしてそれが証拠に基づくホットスポット分析が示唆するものとどう比較されるかについて正直になってください。

  6. 私たちの現在の上位のホットスポットをもう1年対処しないままにしておくと、欠陥率や提供の鈍化において、私たちにどれだけのコストがかかるでしょうか。 この問いは、ホットスポットを抽象的で容易に優先度下げされる関心事のままにしておくのではなく、優先順位づけの決定を固定できる具体的なコストの見積もりを強制します。

業種別の視点

スタートアップ。 正式なホットスポット分析は、チーム全体が今も集合的に頭の中に保持している小さく若いコードベースでは通常不要です。この技法は、コードベースが、どの個人も記憶だけで最悪の領域を確実に特定できる規模を超えて成長したとき、特に持続的な成長の最初の1年か2年のどこかで、価値を持つようになります。

中小企業。 無料か低コストのツールは、最小限のセットアップで既存のバージョン管理の履歴から直接チャーンのデータを抽出できます。この規模で専用の商用ホットスポット分析ソフトウェアに投資するのではなく、それを、あなたの既存のリンターや静的解析ツールがすでに報告している複雑さのデータと組み合わせてください。

企業。 ホットスポット分析は、証拠に基づく優先順位づけが最大の見返りを発揮する場所です。なぜなら、直感は、何百ものサービスと何千ものファイルにまたがるコードベースの規模では本物に失敗するからです。コードベース全体にわたってこの分析を定期的に実行し、インシデントデータと相互参照して、リファクタリングへの投資のための検証され擁護可能な事例を構築することに投資してください。

政府。 時には数十年前のものである長寿命のシステムは、ホットスポット分析に自然に適しています。なぜなら、蓄積されたバージョン管理の履歴は、システムのどの部分が時間とともに本物に問題を証明してきたかについての豊かで長期的な信号を提供するからです。この証拠に基づくアプローチはまた、資金提供を承認するためにエンジニアの非公式な意見以上のものを必要とする利害関係者に近代化投資を正当化するための、説得力のある具体的な道具でもあります。

事例

企業。 数十のサービスにまたがる200万行を超えるコードを持つある保険会社の保険金請求処理プラットフォームは、「保険金請求検証モジュール」が問題だという非公式な苦情を何年も蓄積していましたが、それらの苦情から正式な優先順位づけが行われたことは一度もありませんでした。6か月分のチャーンデータと複雑さのスコアを組み合わせたホットスポット分析は、まったく別のファイル、めったに議論されない依存関係の奥深くに埋もれた共有の通貨変換ユーティリティを、実際の最上位ホットスポットとして特定しました。これはどの振り返りの苦情にも一度も上がったことのないものでした。インシデントデータとの相互参照は、このユーティリティが前年の財務計算の欠陥の不均衡な割合に関与していたことを確認し、誰もが非公式に非難していたモジュールではなく、その特定のユーティリティの的を絞ったリファクタリングは、その後の四半期内に関連するインシデントの測定可能な削減を生み出しました。

政府。 ある州の自動車管理機関の何十年も前からあるライセンス発行システムは、近代化のビジネスケースの一部としてホットスポット分析を受けました。この分析は、コードベース全体の3%未満を代表する小さなファイルの集まりを、チャーンと複雑さの両方の不均衡な割合に責任があるものとして特定し、機関のインシデントログとの相互参照は、まさにこの集まりが過去3年にわたって報告されたすべてのシステム欠陥のほぼ40%を占めていたことを示しました。「システムは古く、近代化が必要だ」という一般的な主張よりもはるかに説得力のあるこの具体的で証拠に基づく発見は、はるかに高価な完全なシステム置き換えではなく、その集まりに特に焦点を当てた、的を絞った段階的な近代化の取り組みのための成功した予算要求の中心になりました。

ビジネスケース:動機、ROI、総所有コスト

ホットスポット分析からの見返りは、的を絞った証拠に基づく投資です。上記の両方の事例は、正式な分析が、非公式な苦情が焦点を当てていた場所からリファクタリングの注意をそらし、データが実際に問題が生きていることを示した場所へと向け直し、的を絞らない、あるいは直感に駆動された投資よりも測定可能に良い見返りを生み出したケースを示しています。

総所有コストは低いものです。なぜなら、チャーンのデータは既存のバージョン管理の履歴から直接得られ、複雑さのデータは通常すでに静的解析のツール(トピック4.4)から利用可能だからです。主な投資は、定期的な分析の労力と、結果を解釈し、特定された各ホットスポットがどんな行動を正当化するかを決める人間の判断の時間です。

アンチパターンと落とし穴

  • 複雑さなしにチャーンだけを使う。 それ単独では弱い信号であり、健全で活発に開発されているコードを偽陽性として旗立てすることがあります。
  • ホットスポットのランキングを人間の判断なしの自動的な行動リストとして扱う。 正しい対応を決定する本質的対偶有的の区別を見逃します。
  • 証拠ではなく最も声の大きい苦情に基づいてリファクタリングを優先順位づけする。 頻繁に、データが実際に問題が生きていることを示す場所から努力を誤導します。
  • ホットスポットをインシデントや欠陥のデータと一度も相互参照しない。 その分析に行動するための事例を強化する検証のステップを見逃します。
  • 分析を一度だけ実行し二度と繰り返さない。 是正の努力が実際に時間とともに機能しているかを見逃します。
  • なぜ是正が定着しなかったかを調査せずに、持続的に旗を立てられたホットスポットを無視する。 繰り返される分析の診断的な価値を無駄にします。

成熟度モデル

  • レベル1、開始: リファクタリングの優先順位は直感や苦情の量によって設定され、チャーンや複雑さのデータが決定に情報を与えることはありません。
  • レベル2、発展: 一部のチームは非公式にチャーンや複雑さのデータを確認しますが、一貫した組織全体のホットスポット分析の慣行はありません。
  • レベル3、標準化: チャーンと複雑さを組み合わせたホットスポット分析が定期的かつ一貫して実行され、組織全体でリファクタリングの優先順位づけに情報を与えています。
  • レベル4、管理: ホットスポットは分析を検証するためにインシデントと欠陥のデータと相互参照され、連続するサイクルにわたる傾向が能動的に追跡されています。
  • レベル5、最適化: 組織は、ホットスポットに情報を与えられたリファクタリングへの投資からの具体的で測定可能な欠陥率や提供の改善を指し示すことができ、この分析はエンジニアリング投資の決定への日常的で信頼される入力です。

議論のためのアイデア

  1. もし今日この分析を実行したら、私たちの上位のホットスポットのリストはどう見えるでしょうか。
  2. そのリストは、私たちの最悪の問題領域についてのチームの現在の非公式な感覚と一致するでしょうか、それとも矛盾するでしょうか。
  3. 私たちはホットスポットを実際のインシデントと相互参照するためのデータを持っているでしょうか。
  4. 既知の問題領域は、それを修正する以前の試みにもかかわらず持続したことがあるでしょうか、そしてなぜでしょうか。
  5. 私たちの現在の上位のホットスポットをもう1年対処しないままにしておくと、私たちにどれだけのコストがかかるでしょうか。

主な要点

  • チャーンと複雑さの組み合わせは、どちらか一方の指標だけよりもはるかに確実に本物のホットスポットを特定します。
  • ホットスポット分析は手動の調査を必要としません。 それは既存のバージョン管理と静的解析のデータから自動的に計算可能です。
  • ホットスポットのランキングを優先順位づけのための証拠として扱い、自動的な判決としては扱わないでください。今も人間の判断が必要です。
  • 分析を検証しそれに行動するための事例を強化するために、ホットスポットをインシデントと欠陥のデータと相互参照してください。
  • 是正が実際に機能していることを確認するために、一度きりの一時点としてではなく連続する分析サイクルにわたってホットスポットを追跡してください。

参考文献とさらなる読書

  • Your Code as a Crime Scene, Adam Tornhill 著。
  • Software Design X-Rays, Adam Tornhill 著。
  • Nagappan, Nachiappan, and Thomas Ball, “Use of Relative Code Churn Measures to Predict System Defect Density,” ICSE (2005)。
  • Refactoring: Improving the Design of Existing Code, Martin Fowler 著。