プロジェクトに存在する技術的負債の量をどのように数量化できますか？
誰かがコードベースの一種として、コードベースの技術的負債に数を置く何らかのツールがあるかどうか知っていますか？そうでない場合、誰かがそのアルゴリズムまたは一連のヒューリスティックを知っていますか？
これらのどちらも今のところ存在しない場合は、そのようなことから始める方法のアイデアに興味があります。つまり、メソッド、クラス、名前空間、アセンブリなどによって発生した技術的負債をどのように数量化できますか？.
私はC＃コードベースの分析と評価に最も興味がありますが、特に概念が言語の超越的なものである場合は、他の言語にも気軽に参加してください。
技術的負債は、システムの設計、構築、テスト、および保守のどこかの段階で、製品のテストおよび保守がより困難になるような特定の決定が行われたという抽象的な概念にすぎません。技術的負債が増えると、システムの開発を継続することがより困難になります。技術的負債に対処し、それ以外の場合は単純なタスクであることに、より多くの時間を割り当てる必要があるか、またはリソースを投資する必要があります（時間とお金）コードのリファクタリング、テストの改善などにより、技術的負債を削減します。
コードの品質に関していくつかの指標を与えるかもしれないいくつかの指標があります：
- コードカバレッジ。そこには さまざまなツールがあります は、関数、ステートメント、および行の何パーセントが単体テストでカバーされているかを示します。また、システムおよび受け入れテストを要件にマッピングして、システムレベルのテストでカバーされる要件の割合を決定することもできます。適切なカバレッジは、アプリケーションの性質によって異なります。
- Coupling および cohesion 。結合が低く、凝集度が高いコードは、通常、読みやすく、理解しやすく、テストも簡単です。特定のシステムの結合と凝集の量を報告できるコード分析ツールがあります。
- 循環的複雑度 は、アプリケーションを通る一意のパスの数です。通常、メソッド/関数レベルでカウントされます。循環的複雑度は、モジュールの理解可能性とテスト容易性に関連しています。サイクロマティック複雑度の値が高いほど、コードの実行に問題が発生するだけでなく、カバレッジを達成するために必要なテストケースの数もわかります。
- さまざまな Halstead複雑さの尺度 は、コードの可読性に関する洞察を提供します。これらは、演算子とオペランドをカウントして、ボリューム、難易度、および労力を決定します。多くの場合、これらは、多くの場合、コードレビューやコードベースの新しい開発者など、コードを取得して理解するのがどれほど難しいかを示します。
- 重複するコードの量。コードの重複は、メソッドへのリファクタリングの可能性を示している可能性があります。コードが重複していると、バグが発生する行が多くなり、同じ欠陥が複数の場所に存在する可能性が高くなります。同じビジネスロジックが複数の場所に存在する場合、変更に対応するためにシステムを更新することが難しくなります。
多くの場合、 静的分析ツール は潜在的な問題を警告することができます。もちろん、ツールが問題を示しているからといって、問題があることを意味するわけではありません。何かが問題になる可能性があるかどうかを判断するには、人間の判断が必要です。これらのメトリックは、システムまたはモジュールをより詳細に検討するときかもしれないという警告を与えるだけです。
ただし、これらの属性はコードに重点を置いています。これらは、さまざまな品質属性に関連するシステムアーキテクチャまたは設計の技術的負債をすぐに示すものではありません。
ソナー には、ソフトウェアプロジェクトに役立つ技術的な負債のヒューリスティックスといくつかの他の機能があります。
また、かなり幅広い言語をサポートしています。
SonarQube（以前はSonar）は、コード品質...
- 25以上の言語をサポート：Java、C/C++、C＃、PHP、Flex、Groovy、JavaScript、Python、PL/SQL、COBOLなど。
- SonarQubeは、Android開発に使用されます。
- 重複したコード、コーディング標準、単体テスト、コードカバレッジ、複雑なコード、潜在的なバグ、コメント、設計とアーキテクチャに関するレポートを提供します。
- タイムマシンと差分ビュー。
- 完全に自動化された分析：Maven、Ant、Gradleおよび継続的統合ツール（Atlassian Bamboo、Jenkins、Hudsonなど）と統合します。
- Eclipse開発環境と統合します
- 外部ツールとの統合：JIRA、Mantis、LDAP、Fortifyなど。
- プラグインを使用して拡張可能。
- 実装[〜＃〜] sqale [〜＃〜] 計算方法 技術的負債 ...
私は金融のアナロジーを使うのは嫌いですが、それは本当に適切なようです。何か（あらゆる種類の資産）の価格を設定する場合、それは本質的な価値と外部的な価値の両方を持つことができます。この場合、既存のコードには固有の値があります。これは、そのコードの相対的な品質に対応する量であり、外部値（コードに対して実行できることからの値）もあり、それらの量は加算されます。コードのスコアリングに使用している方法論（コメント/読みやすさは+5、コードカバレッジは-10など）を使用して、本質的な価値をクレジットとデビット（良いか悪いか）に分類できます。
今日、これを定量化するツールは確かに知りません。さまざまな「債務評価」戦略のメリットを主張すれば、まったく新しい議論ができると思いますが、マシューに同意します。債務はコードを入手するために必要な工数を費やすために使用する方法を使用して、コードを可能な限り入手するための累積コスト。
考慮すべき他のことは、「完全性」に近づくにつれて、コードベースに費やされる1時間の値はおそらく指数関数的に減少する可能性が高いため、おそらく追加の最適化問題があるという費用効果の測定があることです。行われた作業のユーティリティを最大化します。
開発者の間では、技術的負債のかなり信頼できる尺度は WTFs /分 のようです。
この「メトリック」の問題は、通常、「外部」とのコミュニケーションがかなり難しいことです。
「部外者」への技術的負債の伝達で私のために機能した測定基準は、テストとバグ修正の労力（特に 回帰バグ）の修正 ）配信を成功させるために必要です。
注意：このアプローチは非常に強力ですが、それに頼る前に、古き良きWTFs/minuteでダブルチェックするほうがよいでしょう。物事は、それはかなり面倒です：データを取得するには、時間を注意深く追跡し、適切なカテゴリごとに正確に記録する必要があります。
- 簡単に言うと3週間合計で機能の実装に費やしたAより
私は機能Aのドラフト実装に14時間費やし、その後煙テストに29時間費やし、その後、発見したリグレッションの修正の実装に11時間費やし、QA対応機能実装のテストに18時間費やしました。その後、QA担当者は最初の候補者リリースのテストに17時間費やしました。その後、QAから提出された最初の候補リリースのバグを13時間分析し、修正を実装するのに3時間費やしました。その後、最初の候補者リリースに加えた変更を煙のテストに11時間費やしました。その後...
とにかく、テストとバグ修正の取り組みに関するデータは、私の経験では簡単に伝えることができました。
最近のリリースでは、回帰バグのテストと修正に約90％の時間を費やしました。次のリリースでは、この値を60〜70％に下げるためにいくつかの作業を割り当てることをお勧めします。
もう一つの注意点。上記の90％のようなデータは、技術的負債の兆候として解釈されるだけでなく、プログラミング/特定のテクノロジーに精通していないことの兆候としても解釈できます。 「コードにバグを作りすぎる」.
データがそのように誤って解釈されるリスクがある場合は、比較対象の少ないWTF傾向があるに関する追加の参照データを用意すると役立ちます。
- 同じ開発者によって維持されている2つの類似したコンポーネント/アプリケーションがあり、最初は「廃棄率」約50％でリリースし、次に80-90でリリースする場合、これはを支持するかなり強力なケースになります2番目は技術的負債の対象です。
プロジェクトに専任のテスターがいる場合は、データのより客観的な評価にも貢献できます。 別の答え で述べたように、
テスターを使用すると、設計の問題についての理解をバックアップしてもらうことができます。 code qualityについて不平を言う開発者しかいない場合、これはしばしば 閉じられたドアの後ろからの主観的なWTF のように聞こえます。
しかし、これがQAの担当者によってcomponent Aのように言ってエコーされた場合、10の回帰バグがあったcomponent Bとは対照的に、10の新機能に対して100の回帰バグがありました。 20の新機能ごとに、通信が突然別のゲームに変わります。
問題は、技術的負債を「返済」するのにどれくらいの費用がかかるか、つまりそれを修正するのにどれだけの労力が必要かということだと思います。それを理解するのはチーム次第です。
スプリントの計画中に、ユーザーストーリーの複雑さを推定するのと同じ方法で、技術的な負債項目の修正の複雑さを推定するようにチームに依頼します。その時点で、現在のスプリント（実際のユーザーストーリーを置き換える）で実行するのに十分な優先順位である技術的負債と、何を待つことができるかを判断するのは、チームと製品所有者の間の交渉ゲームです。
あなたがスクラムをやっていないのなら、私は私の前提に固執します-技術的負債は救済の費用によって測定されるべきです。
[〜＃〜] cast [〜＃〜] と呼ばれる非常に強力なプラットフォームがあり、大きなアプリケーションの技術的負債を探しています。レガシーシステムの大幅な機能強化を引き継いだプロジェクトで使用しました。コードを書いた人の頭の中に何があったかはわかりませんが、コードを調べてコードとアーキテクチャの欠陥を見つけ、必要に応じて技術的負債を定量化します。ただし、これを確認する実際の用途は、$の金額ではなく、コードに既に含まれている問題のリストです。これは、あなたが持っている技術的負債の一部についてあなたに伝えます（私は上記の答えのいくつかに同意しません）。純粋にデザインベースであり、ポルノのように非常に主観的な技術的負債がいくつかあります。それが本当に「技術的な」借金なのか、と私は主張します。純粋に実装にある技術的な負債がいくつかありますが、測定して追跡する価値があると思います。
これは、MITからのウェビナーで、大規模なソフトウェアシステムの技術的負債に関する研究について説明しています。 http://sdm.mit.edu/news/news_articles/webinar_050613/sturtevant-webinar- technical-debt.html
著者は、プロジェクトを分析して「アーキテクチャの複雑さ」の測定基準を引き出すコードを書きました。これらの指標は、欠陥密度、開発者の生産性、開発スタッフの離職率と強い関係があることが示されました。
ウェビナーで説明されている作業は、ハーバードビジネススクールのアランマコーマックとカーリスボールドウィンによって行われたモジュール性の研究に基づいています。私も彼らの論文を見ました。それらの「伝播コスト」は、あなたが探しているものかもしれません。
標準コードメトリックスは、技術的負債の高レベル相対ビューとして使用できます。 VS Ultimateには、Cyclomatic Complexity、Coupling、LoC、およびDepth of Inheritanceに基づく「Maintainability Index」を提供するコードアナライザーが含まれています。問題のある場所に飛び込んで詳細を確認できます（機能レベルまで）。プロジェクトで実行したところ、データパッケージ（EFの構成と初期化）とテストスイートで得た最低スコアは69でした。それ以外はすべて90以上でした。ボブおじさんの [〜＃〜] ppp [〜＃〜] には、より多くのメトリックスを提供する他のツールがあります 説明したものと同様
私はこれを正確に調査している会社で働いています。以下は、技術的負債に取り組むときに検討することをお勧めする3つの実用的な指標です。それらを追跡する「方法」と「時期」の詳細については、要約記事 つの指標を理解し、技術的負債に取り組む をまとめました。
あなたの考えは何ですか？質問に答えて喜んで、あなたのフィードバックを聞いて空腹:)。
欠陥と不要な技術負債を防ぐための所有権
所有権はエンジニアリングヘルスの主要な指標です。
多くの人からの寄稿を受け取ったコードベースの部分は、時間の経過とともに蓄積を蓄積しますが、少数の人から寄稿を受け取った部分は、より良い状態になる傾向があります。コードベースの一部について十分な情報を持っている密集したグループで高水準を維持する方が簡単です。
これはいくつかの予測力を提供します。コードベースの弱く所有された部分は、時間の経過とともに借金を蓄積し、作業がますます困難になる可能性があります。特に、不完全な情報とコードの品質の所有権の希薄化の副作用として、借金が意図せずに引き継がれる可能性があります。
これは コモンズの悲劇 に似ています。
アーキテクチャを改善するための結束
凝集度は、明確に定義されたコンポーネントの後続のインジケーターです。
凝集性とその対応物である結合は、ソフトウェアを設計するときに焦点を当てるべき重要な概念として長い間認識されてきました。
コードは、その要素のほとんどが一緒に属している場合、凝集度が高いと言われています。高い凝集性は、保守性、再利用性、および堅牢性に関連するため、一般的には望ましいものです。高い凝集力と疎結合は密接に関係します。
再利用性と保守性の高いコードに関連付けられるだけでなく、凝集度が高いと、コードベースの特定の部分を変更して生産性を向上させるために関与する必要がある人の数も最小限に抑えられます。
問題領域を特定するためのチャーン
チャーン（繰り返されるアクティビティ）は、成長するシステムでリファクタリングに適した領域を特定してランク付けするのに役立ちます。
システムが成長するにつれて、開発者がアーキテクチャを理解することが難しくなります。開発者が新しい機能を提供するためにコードベースの多くの部分を変更する必要がある場合、バグの原因となる副作用の導入を回避することは困難であり、より多くの要素と概念に慣れる必要があるため、生産性が低下します。
このため、より安定したシステムを作成し、意図しない結果を回避するために単一の責任を果たすことが重要です。一部のファイルはアーキテクチャーハブであり、新しい機能が追加されてもアクティブのままですが、ファイルにクロージャをもたらすような方法でコードを記述し、厳密にレビュー、テスト、およびQAチャーニング領域を作成することをお勧めします。
チャーンはこれらのアクティブなファイルを表面化するので、コードベースの変更の表面領域を減らすためにそれらを分解する必要があるかどうかを決定できます。
技術的負債を、それを定量化するためのファンシーなモデルが必要なドルとは考えません。私はそれを好意と考えます。誰かがあなたに好意を示し、あなたが忘れそうな場合は、それを書き留めます。近道をするときは、それを書き留めてください。これはあなたが覚えるのを助け、より無力なあなたはそれを認めるように強制します。豪華なツールは必要ありません。メモ帳やEcxelでうまくいく。