ある種のコードメトリックとして、コードベースの技術的負債に数字を付ける何らかのツールがあるかどうか、誰もが知っていますか？そうでない場合、誰かがアルゴリズムまたはヒューリスティックのセットを知っていますか？

これまでのところそれらのいずれも存在しない場合、私はそのようなことから始める方法のアイデアに興味があります。つまり、メソッド、クラス、名前空間、アセンブリなどによって発生した技術的負債をどのように定量化できますか。

私はC＃コードベースの分析と評価に最も関心がありますが、特に概念が言語を超越している場合は、他の言語でも気軽に声をかけてください。

技術的負債は、システムの設計、構築、テスト、およびメンテナンスのどこかに沿って、製品のテストとメンテナンスがより困難になるような特定の決定が行われたという抽象的な概念です。より多くの技術的負債があるということは、システムの開発を継続することがより難しくなることを意味します。コード）のリファクタリング、テストの改善などにより、技術的な負債を減らすことになります。

コードの品質に関していくつかの指標を与える可能性のあるメトリックスがいくつかあります。

• コードカバレッジ。ユニットテストでカバーされる関数、ステートメント、および行の割合を示すさまざまなツールがあります。また、システムおよび受け入れテストを要件にマップして、システムレベルのテストでカバーされる要件の割合を決定することもできます。適切なカバレッジは、アプリケーションの性質によって異なります。
• カップリングと凝集。低い結合と高い凝集度を示すコードは、通常、読みやすく、理解しやすく、テストしやすいです。特定のシステムの結合と結合の量を報告できるコード分析ツールがあります。
• 循環的複雑度は、アプリケーションを通る一意のパスの数です。通常、メソッド/関数レベルでカウントされます。循環的な複雑さは、モジュールの理解可能性とテスト可能性に関連しています。循環的複雑度の値が高いほど、コードを追跡するのに手間がかかることを示すだけでなく、循環的複雑度は、カバレッジを達成するために必要なテストケースの数も示します。
• さまざまなHalsteadの複雑さの尺度は、コードの可読性に関する洞察を提供します。これらは、演算子、オペランドをカウントして、ボリューム、難易度、および労力を決定します。多くの場合、これらは、コードレビューやコードベースの新規開発者などの場合に、誰かがコードを拾って理解することがどれほど難しいかを示すことができます。
• 重複コードの量。コードの重複は、メソッドへのリファクタリングの可能性を示す場合があります。重複コードがあるということは、バグが導入される行が多くなり、同じ欠陥が複数の場所に存在する可能性が高くなることを意味します。同じビジネスロジックが複数の場所に存在する場合、変更を考慮してシステムを更新するのが難しくなります。

多くの場合、静的分析ツールは潜在的な問題を警告することができます。もちろん、ツールが問題を示しているからといって、問題があることを意味しているわけではありません。何かが問題になる可能性があるかどうかを判断するには、人間の判断が必要です。これらのメトリクスは、システムまたはモジュールをより詳しく調べる時間である可能性があることを警告するだけです。

ただし、これらの属性はコードに焦点を合わせています。これらは、システムアーキテクチャまたは設計のさまざまな品質属性に関連する可能性のある技術的負債を容易に示すものではありません。

Sonarには、ソフトウェアプロジェクトに役立つ技術的な負債ヒューリスティックな機能がいくつかあります。

また、かなり幅広い言語をサポートしています。

SonarQube（旧Sonar）は、コード品質の継続的な検査のためのオープンソースプ...

• 25以上の言語をサポート：Java、C / C ++、C＃、PHP、Flex、Groovy、JavaScript、Python、PL / SQL、COBOLなど
• SonarQubeはAndroid Deveopmentでも使用されます。
• 重複コード、コーディング標準、単体テスト、コードカバレッジ、複雑なコード、潜在的なバグ、コメント、設計、アーキテクチャに関するレポートを提供します。
• タイムマシンと差分ビュー。
• 完全に自動化された分析：Maven、Ant、Gradle、および継続的統合ツール（Atlassian Bamboo、Jenkins、Hudsonなど）と統合します。
• Eclipse開発環境と統合します
• JIRA、Mantis、LDAP、Fortifyなどの外部ツールと統合します。
• プラグインを使用して拡張可能。
• SQALE方法論を実装して、技術的な負債を計算します...

私は金融からのアナロジーを使用することを嫌いますが、それは本当に適切なようです。何か（あらゆる種類の資産）の価格を設定する場合、本質的価値と外的価値の両方を持つことができます。この場合、既存のコードには、そのコードの相対的な品質に対応する量である固有の値があり、また、外部の値（コードにできることからの値）があり、それらの量は加算的です。本質的な価値は、コードのスコアリングに使用する方法を使用して、クレジットとデビット（良い対悪い）に分類できます（コメント/読みやすさの+5、コードカバレッジの-10など）。

私は確かに今日これを定量化するツールを知りません。異なる「債務評価」戦略のメリットを主張するなら、あなたは完全に新しい議論をあなたが持っていると思いますが、私はマシューに同意します-債務はコードを可能な限り入手するための累積コスト。そこに到達するために必要な工数を費やすために使用する方法を使用します。

考慮すべき他のことは、「完璧」に近づくにつれて、コードベースに費やされる1時間の値が指数関数的に減少する可能性が高いため、おそらく費用対効果の尺度があることです。完了した作業の有用性を最大化します。

開発者の間では、技術的負債のかなり信頼できる尺度は、WTF /分と思われます。

_{この「メトリック」の問題は、通常「外部」と通信することがかなり難しいことです。}

技術的な負債を「部外者」に伝える上で役立った指標は、配信を成功させるために必要なテストとバグ修正の努力（特に回帰バグの修正）でした。

注意点：このアプローチは非常に強力ですが、それに頼る前に、古き良きWTF /分でダブルチェックする方が良いでしょう。つまり、データを取得するには、時間を慎重に追跡し、適切なカテゴリごとに正確に記録する必要があります。

• それはそんなに簡単な状態にある3週間の合計を過ごした機能Aを実装するよりも、
   
  私はQAテスト私は、その後18時間、発見された回帰のための修正を実装する上で、その後29時間スモークテストに機能Aのドラフト実装上で、その後11時間を14時間を費やし-すぐに機能を実装。その後、QAチームは最初の候補リリースのテストに17時間を費やしました。その後、最初の候補リリースでQAから提出されたバグの分析に13時間、修正の実装に3時間を費やしました。その後、最初の候補リリースに加えた変更をテストするために11時間を煙に費やしました。その後...

とにかく、テストとバグ修正の取り組みに関するデータは、私の経験では簡単に伝えることができました。

最近のリリースでは、回帰バグのテストと修正に約90％の時間を費やしました。次のリリースでは、この値を60〜70％に下げるための努力を割り当てることをお勧めします。

別の注意点。上記の90％のようなデータは、技術的負債の兆候としてだけでなく、プログラミング/特定の技術にあまり精通していないことの兆候として（驚き）とも解釈できます。「コードにバグを作りすぎている」。

データがそのように誤って解釈されるリスクがある場合は、比較する傾向があるWTFの少ないものに関する追加の参照データを用意しておくと役立ちます。

• 同じ開発者が保持する2つの類似のコンポーネント/アプリケーションがあり、最初に約50％の「廃棄率」でリリースされ、次に80-90で2番目にリリースされる場合、2番目は技術的負債の対象になります。

プロジェクトに専用のテスターがいる場合、データのより客観的な評価にも貢献できます。別の答えで述べたように、

テスターを使用すると、設計の問題についての理解をバックアップすることができます。開発者だけがコード品質について不平を言うとき、これはしばしば密室からの主観的なWTFのように聞こえます。
 
しかし、QAの男component Aが、10個の新機能に対して100個の回帰バグがあり、component B20個の新機能ごとに10個の回帰バグがあったのに反して、通信が突然まったく別のゲームに変わったと反論すると、

問題は、技術的負債を「返済」するのにどれくらいの費用がかかるか、つまり、それを修正するのにどれだけの労力がかかるかだと思います。それを理解するのはチーム次第です。

スプリントの計画中に、ユーザーストーリーの複雑さを推定するのと同じ方法で、技術的な負債項目の修正の複雑さを推定するようチームに依頼します。その時点で、現在のスプリントで実行するのに十分な優先度の高い技術的負債（実際のユーザーストーリーを置き換える）と何を待つことができるかを判断するのは、チームとプロダクトオーナーの間の交渉ゲームです。

スクラムをしていないなら、私は私の前提に固執します-技術的な負債は治療のコストで測定されるべきです。

CASTと呼ばれる非常に強力なプラットフォームがあります大きなアプリケーションで技術的な負債を探すために。レガシーシステムの大幅な拡張を引き継いだプロジェクトで使用しました。それは、コードを書いた人々の頭の中に何があったのかを教えてくれませんが、コードを調べて、コードとアーキテクチャの欠陥を見つけて、必要に応じて技術的な負債を定量化します。ただし、これを実際に使用するのは、金額ではなく、コードに既に存在する問題のリストです。これは、あなたが持っている技術的負債の一部について教えてくれます（したがって、上記の答えのいくつかには同意しません）。純粋にデザインベースであり、ポルノのように非常に主観的な技術的負債がいくつかあります。それが本当に「技術的な」負債なのかどうかを議論します。純粋に実装にあるいくつかの技術的負債があり、私はそれを信じています

これは、大規模なソフトウェアシステムの技術的負債に関する研究を説明するMITのウェビナーです。http： //sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar-technical-debt.html

著者は、プロジェクトを分析し、「アーキテクチャの複雑さ」メトリックを引き出すためのコードを作成しました。これらのメトリックは、欠陥密度、開発者の生産性、および開発スタッフの離職率と強い関係があることが示されました。

ウェビナーで説明されている作業は、ハーバードビジネススクールでアランマコーマックとカーリスボールドウィンが行ったモジュール性の研究に基づいています。私も彼らの論文を見るでしょう。彼らの「伝播コスト」はあなたが探しているものかもしれません。

標準的なコードメトリックは、技術的な負債の高レベルの相対的なビューとして使用できると思います。VS Ultimateには、循環的複雑度、結合、LoC、および継承の深さに基づいた「保守性インデックス」を提供するコードアナライザーが含まれています。トラブルスポットに飛び込んで詳細を確認できます（機能レベルまで）。プロジェクトで実行したところ、データパッケージ（EFの構成と初期化）とテストスイートで得られた最低スコアは69でした。それ以外はすべて90以上でした。ボブおじさんのPPPで説明されているようなより多くのメトリックを提供する他のツールがあります

私は、技術的な負債を、それを定量化するための派手なモデルが必要なドルとは考えません。私はそれを好意的だと思うでしょう。誰かがあなたに好意を与え、あなたが忘れそうな場合、あなたはそれを書き留めます。ショートカットを取るとき、それを書き留めてください。これはあなたが覚えているのを助け、より無力なことはあなたにそれを認めるように強制します。派手なツールは必要ありません。メモ帳またはEcxelがこのトリックを実行できます。

私はこれを正確に検討している会社で働いています。以下は、技術的負債に取り組むときに検討することをお勧めする3つの実用的な指標です。それらを追跡する「方法」と「いつ」の詳細については、技術的な債務を理解し、取り組むための要約記事3メトリクスをまとめました。

あなたの考えは何ですか？ご質問にお答えし、ご意見をお聞かせください:)。

欠陥および不要な技術負債を防ぐための所有権

所有権は、エンジニアリングの健全性の主要な指標です。

多くの人々から貢献を受け取っているコードベースの部分は、時間の経過とともにクズを蓄積しますが、少数の人々から貢献を受け取った部分は、より良い状態になる傾向があります。コードベースの部分について十分な情報を得ている緊密なグループで高い標準を維持するのは簡単です。

これにより、ある程度の予測力が得られます。コードベースの弱く所有されている部分は、時間の経過とともに負債を蓄積し、作業がますます難しくなります。特に、単に不完全な情報とコードの品質の所有権の希薄化の副作用として、意図せずに借金を引き受ける可能性があります。

これはコモンズの悲劇と幾分類似しています。

アーキテクチャを改善するための結束

凝集度は、明確に定義されたコンポーネントの末尾のインジケータです。

Cohesionとそれに対応するカップリングは、ソフトウェアを設計するときに焦点を当てる重要な概念として長い間認識されてきました。

コードは、その要素のほとんどが一緒に属する場合、高い凝集性を持つと言われています。一般に、保守性、再利用性、および堅牢性に関連するため、高い凝集度が好まれます。高い凝集力と疎結合は、密接に関連する傾向があります。

より高い再結合性と保守性の高いコードに関連付けられるだけでなく、高い凝集度は、コードベースの特定の部分を変更するために関与する必要のある人の数を最小限に抑え、生産性を向上させます。

問題領域を特定するために解約する

チャーン（繰り返しアクティビティ）は、成長しているシステムでリファクタリングの準備ができている領域を特定してランク付けするのに役立ちます。

システムが成長するにつれて、開発者は自分のアーキテクチャを理解することが難しくなります。開発者が新しい機能を提供するためにコードベースの多くの部分を変更する必要がある場合、バグにつながる副作用の導入を避けることは難しく、より多くの要素と概念に慣れる必要があるため、生産性が低下します。

これが、より安定したシステムを作成し、意図しない結果を回避するために単一の責任に努めることが重要である理由です。一部のファイルはアーキテクチャハブであり、新しい機能が追加されてもアクティブのままですが、ファイルを閉じて、厳密にレビュー、テスト、およびQAチャーニングする領域をもたらす方法でコードを記述することをお勧めします。

チャーンはこれらのアクティブなファイルを表面化するので、コードベースの変更の表面積を減らすためにそれらを分解する必要があるかどうかを決定できます。

バグトラッカーやある種のアジャイルソフトウェアを使って良い歴史を持っているなら、それをシンプルに保つことができます。基本的なタスクの完了に費やした時間。また、プロジェクトが現在と比較して若かったときの見積もりの​​信頼性。