技術的負債の概要

技術的負債 は、完了に時間がかかるより良いプラクティスを使用するのではなく、今日簡単なソリューションを選択することによって生まれる将来のコストを表す用語です。

「技術的負債」という用語は、金融負債に似ているため選択されました。 借金を抱える人々がその場では正しいと思われたり、唯一の選択肢と思われたりする決定をすることが一般的ですが、それによって利子が増加します。

関心が高まるほど、将来は難しくなり、後で使用できるオプションが少なくなります。 金融負債では、間もなく利息が増加し、雪だるま効果が生まれます。 同様に、技術的負債が蓄積すると、開発者は、価値を追加するのではなく、計画的または計画外の問題修正ややり直しにほとんどの時間を費やすことになります。

では、どのように起こるのでしょうか。

最も一般的な言い訳は、厳しい期限です。 開発者がコードをすばやく作成することを余儀なくされると、多くの場合、ショートカットが使用されます。 たとえば、メソッドをリファクタリングして新しい機能を含める代わりに、メソッドをコピーして新しいバージョンを作成する場合があります。 その後、新しいコードのみをテストし、コードの他の部分で使用されるため、元のメソッドを変更する場合に必要なテストレベルを回避できます。

現在、同じコードのコピーが 2 つ存在しており、1 つだけを扱っていた場合と異なり、将来的にはそれぞれを変更する必要が生じます。また、ロジックが異なってしまうリスクがあります。 多くの原因があります。 たとえば、開発者の間で技術的なスキルと成熟度が不足しているか、明確な製品所有権や方向性がない可能性があります。

組織はコーディング標準をまったく持っていない可能性があるため、開発者は何を生成すべきかさえ知りませんでした。 開発者がターゲットとする明確な要件がない場合や、直前の要件変更の対象となる可能性があります。

必要なリファクタリング作業が遅れる可能性があります。 手動または自動化されたコード品質テストがない可能性があります。 最終的には、妥当な期間と妥当なコストで顧客に価値を提供することが困難になり、困難になります。

技術的負債は、プロジェクトが期限を満たできない主な理由の 1 つです。

時間の経過と同時に、金銭的負債とほぼ同じ方法で増加します。 技術的負債の一般的な原因は次のとおりです。

• コーディングスタイルと標準の欠如
• 単体テスト ケースの設計が不足しているか、または設計が不十分である
• オブジェクト指向の設計原則を無視する、または理解しない
• モノリシック クラスとコード ライブラリ
• テクノロジ、アーキテクチャ、およびアプローチの十分に計画されていない使用 (メンテナンス、ユーザー エクスペリエンス、スケーラビリティなどに影響するすべてのシステム属性を考慮する必要があることを忘れる)
• 過剰なエンジニアリング コード (不要なコードの追加または作成、既存のライブラリで十分な場合のカスタム コードの追加、または不要なレイヤーまたはコンポーネントの作成)
• 不十分なコメントとドキュメント
• 自己文書化コードを記述しない (説明的または意図を示すクラス、メソッド、変数名を含む)
• 期限に間に合わせるために近道をする
• 実行されないコードが残されています

技術的負債は開発中に問題を追加し、顧客価値を高めるのがはるかに困難であることを確認しました。

プロジェクトで技術的負債を抱えると、生産性が低下し、開発チームが不満を抱き、コードの理解が難しく、脆弱になり、変更を加える時間が長くなり、それらの変更を検証できるようになります。 計画外の作業は、多くの場合、計画された作業の邪魔になります。

長期的には、組織の強さも弱まります。 技術的負債は、組織に忍び寄る傾向があります。 それは小さく始まり、時間の経過とともに成長します。 変更を急ぐ必要があるため、迅速なハッキングが行われるか、テストがスキップされるたびに、問題はますます悪化します。 サポート コストはますます高くなりますが、最終的には重大な問題が発生します。

最終的に、組織はタイムリーかつコスト効率の高い方法で顧客のニーズに対応することはできません。

監視のための自動測定

技術的負債の継続的な蓄積を最小限に抑える重要な方法の 1 つは、自動テストと評価を使用することです。

次のデモでは、負債の評価に使用される一般的なツールの 1 つである SonarCloud を見ていきます。 (元のオンプレミス バージョンは SonarQube でした)。

他にも使用可能なツールがあり、そのいくつかについて説明します。

後で、次のハンズオン ラボでは、SonarCloud を使用するように Azure Pipelines を構成する方法、分析結果を理解する方法、最後に、プロジェクトを分析するときに SonarCloud によって使用されるルール セットを制御するように品質プロファイルを構成する方法について説明します。

詳細については、「 SonarCloud」を参照してください。

確認するには:

Azure DevOps は、ビルド中にコードの品質を確認するために使用されるさまざまな既存のツールと統合できます。

現在使用しているコード品質ツール (ある場合) は何ですか?

ツールについて何が好きですか、好きではないですか?