翻訳者から：

GOTOカンファレンスのビデオを検索しているときに、この興味深い著者Adam Thornhillに出会いました。 この記事が興味深いと思う人には、彼のスピーチを見ることをお勧めします。 私は翻訳に少し混乱しました（助けてくれてターニャに感謝します！）、主題が非常に独特であるように見えたので、私は以前に同様の作品を見たことがありませんでした（コメントのリンクを見てうれしいです！）。 2016年8月の最新記事では、オリジナルはSoftware®Evolution-Part 1と呼ばれています。 テキストは一人称でナレーションされていますが、私は元の記事の著者を意味します。

コード進化により大規模なコードベースを理解する方法

通常、悪いコードは長い時間です。 特定のファイルに残るだけでなく、何年もそこに残り、その作成者（組織内）を助け、サポートを担当する次世代のプログラマーの間で不満を引き起こします。 このコードへの変更は危険な活動です。 現在のコードベースの規模を考えると、システムのそのような部分を特定し、修正、テストの追加作業、またはコードレビューを実行できるようにするためのより効果的なツールが必要です。 この記事では、これらのソリューションに関するガイダンスを得るために、以前の開発動作に関するデータを使用します。

スケールの課題

現在のソフトウェアシステムは、数十万または数百万のコード行で構成されています。 そのようなシステムの規模は、それらを理解することをほとんど不可能にします。 頭の中に数百万行のコードを保持できる人は世界にはほとんどいません。

典型的なシステムは、いくつかの技術スタックと複雑なサブシステムで構成されています

また、今日のシステムはいくつかの異なる技術で構築されています。 例として、フロントエンドJS、JavaまたはNetサービス、およびSQLクエリ言語を使用してデータベースにアクセスする、従来の3層アーキテクチャを考えます。 この技術的な多様性自体はそれほど複雑ではありませんが、大規模システムは異なるチームの開発者によって実装されていることを覚えておく必要があります。 各プログラマーは、コードベースの小さな断片を個別に見ます。 これは、各プログラマーが独自の方法でシステムを提示することを意味し、誰も頭の中で完全なイメージを持っていません。

大規模なコードベースを理解および改善する場合、主なタスクはこれらの技術的および組織的な課題を解決することです。 その結果、ソリューションは要件を満たさなければなりません。

• コードベースのすべての部分をインベントリして、後でアクセスできるように、参加しているすべてのプログラマの集合的な知識を含めます。
• 多言語コードベースを操作するための言語に依存しないアプローチを提示します。
• 数百万行のコードの中で、生産性とリスクの観点から特に重要なコード部分に優先順位を付けます。

残念ながら、CHAOSが発行したレポートのように、ほとんどのプロジェクトが期限や予算を満たしていないことは明らかであり、これは組織にとって弱点です。 私たちの業界には、継続的な失敗の簡単な説明があると思います。 改善の優先順位を付けることは非常に困難です。なぜなら、私たちの判断のほとんどは、現在の状態、つまりシステムの評価に依存しているからです。 彼女のコードに。 しかし、これは不完全な情報だと思います。 つまり、欠落している2つの重要な側面があります。

• 時間。 コード自体だけに基づいて、システムがどのように開発されているかを見ることができず、長期的な傾向を予測することもできません。 開発の一環として、修正し続ける必要があるコードから安定したコードを分離する方法はありません。 後で説明するように、時間ディメンションは、コードの改善に優先順位を付ける能力の鍵です。

  
  
  
  
  
  
  
• 社会情報。 コードだけでは、特定のモジュールが複数のプログラマーの協調的な努力を必要とするパフォーマンスのボトルネックであるかどうかを示すことはできません。 なぜなら コミュニケーションと調整の必要性がソフトウェア業界のコストの推進力であるため、システムに関する情報に基づいた意思決定を行うためのソーシャルコンポーネントが必要です。 驚くかもしれませんが、この社会的要素は管理を超えており、賢明な技術的意思決定を行う能力にとっても同様に重要です。

ソフトウェアの進化をどのように活用して役立つかを見てみましょう。

動作データとしてバージョン管理システムを使用する

データ分析は人気があり、ユビキタスな機械学習は、複雑な現象のパターンを探す方法を教えてくれました。 これらの技術を自分自身に適用し始めたのはごく最近のことです。 このギャップを埋める必要があるので、一連の記事全体がこれに専念します。 私たちのシステムがどのように成長するかをよりよく理解するために、私たち自身の振る舞いのパターン（すなわち、プログラマー）を研究し始めたときに何が起こるかを発見しましょう。

このアプローチの最大の利点は、ほとんどすべてのソフトウェア組織がすでにバージョン管理システムにすべてのデータを持っていることです。 私たちは、この点でそれらについて考えることに慣れていないだけです。 バージョン管理システムは、開発者がコードとどのようにやり取りするかを記述する単なる動作ログです。 バージョン管理データには、いつ、どこで変更が行われたかに関する情報が含まれるだけでなく、変更の作成者に関するレコードの形式でソーシャル情報も含まれます。 バージョン管理からのデータを見てみましょう。

ソフトウェアの進化的視点に向けて

Empearでの日々の仕事として、何百もの異なるコードベースを分析しました。 プログラミング言語やテクノロジに関係なく、何度も何度も出くわすパターンがあります。 これらのパターンを開示することは、大規模なコードベースを理解するのに役立ちます。

3つのグラフを見てください。これらはすべて同じものを示しています。 X軸は、システム内のファイルを、変更の頻度（バージョン管理データから取得したコミットの数）でソートして示します。 Y軸は、各ファイルのコミット数を示します。

グラフ上-さまざまなサブジェクトエリアを持つ3つの完全に異なるシステムからのデータ、さまざまな企業で開発され、さまざまな寿命を持つさまざまなサイズのコードベース自体。 しかし、すべてのグラフは同じ幾何学的分布を示しています。

これらのディストリビューションは、開発活動のほとんどがコードベース全体の比較的小さな部分に集中していると言っています。 すべてのファイルの大部分は、ディストリビューションの「テール」に残ります。つまり、ほとんどまたはまったく変更されないコードを作成します。

このようなコード変更の分布の存在は、いくつかの興味深い結果をもたらします。 まず第一に、改善とリファクタリングを優先するツールを提供します。 複雑なコードのリファクタリングは非常にリスクが高く、費用もかかります。 コードがどのように進化するかを理解することで、人件費を回収する可能性が高い部分に集中できます。 これらは、以下に示すように、ほとんどの開発努力を費やす部分です。

レッドゾーンのファイルに対して行った改善は、パフォーマンスの向上につながる可能性が非常に高いです。 これらは、常に作業しているファイルと同じです。 また、品質の点で変更の頻度が高いファイルを見つけることも重要です。 実際、変更の頻度が高いことは、サポートに関する問題の繰り返しと相関しているということです。 実際、モジュールの変更のメトリックの重要性は非常に高いため、エラー予測の状況では、より複雑なメトリックがより高い価値を提供することはめったにありません。

しかし、これらの発見にもかかわらず、私たちのモデルにはまだ弱点があります。 一番下の行は、コードが同じではないということです。 たとえば、1行のファイルのバージョン番号を増やすことと、トリッキーなネストされた条件付きロジックを使用したC ++の5000行のファイルのバグ修正との間には大きな違いがあります。 最初の変更は少し危険であり、実際的な理由で無視できますが、2番目のタイプの変更はテストとコード検証のフレームワークで特別な注意が必要です。 したがって、予測力を向上させるために、モデルに2番目の次元、つまり複雑度の次元を追加する必要があります。 これがどのように行われるかを見てみましょう。

複雑さの言語に依存しないメトリック

ソフトウェアの複雑さを測定する試みがいくつか行われています。 最も有名なアプローチは、McCabe循環的複雑度とHalstead複雑度です。 これらのメトリックの主な欠点は、それらが言語に関連付けられていることです。 つまり システムで使用されるプログラミング言語ごとに1つのメトリックが必要です。 これは、現代の多言語コードベースの全体的なビジョンに対して言語に依存しないメトリックを提供するという目標と矛盾しています。

幸いなことに、うまくいく単純なメトリック、つまりコードの行数があります。 もちろん、コードの行数は非常に粗雑なメトリックですが、それにもかかわらず、サイクロマティック複雑性などのよく考えられたメトリックとともに、優れた予測力を備えています。 コード行を使用する利点は、メトリックの単純さです。言語に依存せず、直観的にも明確です。 行数を複雑さのメトリックの代わりとして使用し、変更の頻度の測定と組み合わせて、コードベースのホットポイントを示します。

ホットスポットを使用してリスクの高い変更を特定する

ホットスポットは複雑なコードであり、頻繁に使用する必要があります。 GTは、2つの異なるソースから計算されます。1）複雑さの単純化されたメトリックとしてのコード行数2）バージョン管理履歴から取得した各ファイルの変更頻度。

Empearのツール、Empearツールスイートは、ソフトウェアベースのGT分析をコードベース全体を調べることができるインタラクティブマップとして分析します。 以下の視覚化では、各ファイルは円として表されています。

GTマップを使用すると、システムのコンテキストで各GTを表示できます。 視覚化により、問題のあるサブシステムを指すGTクラスターを特定することもできます。 もちろん、このGTの変更の実際の頻度は制限されていません。 これらの側面については、最初にいくつかのユースケースで説明します。

ホットスポットの使用方法

HT分析にはいくつかの用途があり、多くの専門家に役立ちます。

• 開発者はそれらを使用して、サポートの問題を特定します。 多くの場合、使用する必要がある複雑なコードは幸福をもたらしません。 GTは、これらのピースの場所に関する情報を提供します。 この情報を使用して、変更に優先順位を付けます。

  
  
  
  
  
  
  

• 技術リーダーはGTを使用してリスクを管理します。 GTの変更または新しい機能を使用した機能の拡張には、高いリスクが伴います。 GT分析では、これらの場所を事前に識別することができるため、余分な時間を計画したり、テスト用に追加のリソースを割り当てたりできます。

  
  
  
  
  
  
  

• GTは、レビューの候補としてコード内の場所を示します。 コードレビューは欠陥を取り除くのに最適ですが、同時に費用がかかり、手作業であるため、投資した努力が十分に投資されていることを確認したいと思います（コードレビュー後の無関心は本物です）。 この場合、GTカードを使用してレビューの候補者を特定します。

  
  
  
  
  
  
  
• GTは研究テストのエントリポイントです。 マップは、経験豊富なテスターに​​とって、開発者の多くの活動のために不安定と思われるコードベースの部分を識別するための優れた方法です。 この情報を使用して、エントリポイントを選択し、研究テストの重点分野を選択します。

複雑さの傾向と機械学習の詳細

優先GTを特定したら、それらがどのように開発されているかを理解する必要があります。 コードを改善し、将来のリスクを軽減し始めるという意味で、GTについてすでに十分に知っていますか？ 時間がたつにつれてますます混乱するセクションになるため、それらはホットですか、それとも安定したコードの小さな変更の状況ですか？

これらの質問に答えるには、時間の傾向を調べる必要があります。以下を参照してください

この図は、2014年半ばから開始される1つのGTの複雑さの傾向を示しており、過去1年半にわたるGTの開発が見られます。 それは、驚くべき画像になります。なぜなら 複雑さが急速に増大し始めました。 さらに悪いことに、複雑さは新しいコードの量に対して非線形に増加します。つまり、GT内のコードを理解するのが難しくなります。 おまけとして、複雑さが増してもコメントの説明が増えないこともわかります。 これはますます実際のサポートの問題のように見えます。

細心の注意を払うと、気づくかもしれません：複雑さの傾向測定基準は、コードの行と複雑さとは異なります。 コードの行はGTマップのヒューリスティックとして機能しますが、特定の長期トレンドを評価すると、メトリックが粗くなりすぎます。 たとえば、単純にネットサイズが大きくなったファイルと、コードの各行を理解するのが難しくなる場合（多くの場合、論理条件の過剰使用が原因）を区別する必要があります。 どちらのケースにも独自の問題がありますが、2番目のケースには高いリスクが伴います。 つまり、トレンドを計算するときは、言語にもっと集中する必要があります。

多次元ホットスポット

それで、私は以前に、実際のGTは単なる高度な変更以上のものであることに注意しました。 たとえば、GTの基準の一部として複雑さの傾向を検討したいと思います。 Empearのツールがこれを行います。 さらに、同社は、開発の断片化などのデータを分析するときに、変化のより深いパターンを検出する機械学習アルゴリズムを使用しています。 組織レベルでの調整の問題と内部コミュニケーションを特定します。 全体的に、頻繁に変更される混乱するコードは問題です（実際のGT）：

1. GTは、他のいくつかのモジュールと同時に変更する必要があります。
2. GTは、さまざまなチームのさまざまな開発者に影響を与えます。

Empeatは会社に関する情報を収集するため、 チーム構造では、サポートに非常に費用のかかるコードを検出できます。 コードベースの変更のパターンが組織の制約と交差するたびに、調整および通信コストの形で請求書を支払います。

次の図は、このアルゴリズムを多数のオープンソースプロジェクトで実行した後、GTの数を合計コードサイズの少数に削減する方法を示しています。

グラフからわかるように、選択されたGTはコード全体の2〜3パーセントしか占めていません。 同時に、不均衡に大量のコミット（合計の11〜16％）がこれらのGTに集中しています。 これは、優先GTでのコードの改善はすべて時間を費やしたことを意味します。

ホットスポットは、欠陥密度の高い領域を示します

会社を設立して以来、実際のコードベースの分析の確認とテストに多くの時間を費やしています。 私がやったことの1つは、明確に定義されたGTが欠陥を予測する方法を研究することでした。 これは、コード内で修正アクションが実行された場所を特定することで行われました。 次に、バージョン管理履歴を巻き戻し、GTを測定し、相関関係を見つけようとしました。

私たちの結果は、優先GTとコード内のほとんどの欠陥部品との間に強い相関関係があることを示しています。 一般に、優先GTはコードのごく一部を構成しますが、特定および解決されたすべての欠陥の25〜70％を含んでいます。

私の著書「犯罪現場としてのコード」では、Empearツールの開発のエントリポイントとして使用した調査結果のいくつかと、GTが機能する理由と方法について詳しく見ていきます。 ただし、1行で結論を出させてください。

ホットスポット、サポートコスト、ソフトウェアの欠陥の間には強い相関関係があります。 ホットスポットは、コードのパフォーマンスのボトルネックを見つけたい場合に最適なエントリポイントです。Empearツールスイートを使用すると、これまでにない方法でこの知識を利用できます。