技術的負債の概要
技術的負債とは、より適切な対処には時間がかかるために、当面の安易な解決策を選択することによって発生する、将来のコストを示す用語です。
"技術的負債" という用語は、財務的負債との対比のために選択されました。 財務的負債がある人が、その時点では適切または唯一の選択肢と思われる判断をすることは一般的ですが、そうすることで利子は増えていきます。
利子がかさむほど、将来的に困難が増し、後では不利な選択肢ばかりになります。 財務的負債があると、利子に利子が付いて、雪だるま式に増えていきます。 同様に、技術的負債が増大すると、開発者は計画的または計画外の作業で問題の整理と修正にほぼすべての時間を費やし、価値を高める作業ができない状態になることがあります。
どうしてそうなるのでしょうか。
最も一般的な言い訳は、厳しい納期です。 開発者は、コードを短時間で作成するように強制されると、近道をすることがよくあります。 たとえば、新しい機能を追加するためにメソッドをリファクタリングするのではなく、コピーして新しいバージョンを作成するとします。 次に、新しいコードだけをテストします。元のメソッドを変更する場合には、コードの他の部分でそのメソッドが使用されるためにテストが必要になりますが、そのテストのレベルを回避できます。
この場合、将来変更する必要があるコードが 1 つではなく 2 つあることになり、ロジックが分岐してしまう危険性があります。 原因は、さまざまです。 たとえば、開発者の技術的スキルと熟練度が不足している場合や、製品に関する責任や指揮が明確でない場合があります。
組織にコーディング標準がまったくない可能性もあります。 このような場合、開発者は何を制作すればよいのかもわかりません。 開発者には、目標とする正確な要件がなかったかもしれません。 直前になって要件が変更されることもあったりします。
必要なリファクタリング作業は遅れるでしょう。 手動または自動でのコード品質テストも、行われない可能性があります。 最終的に、妥当な期間内に妥当なコストで顧客に価値を提供することが、より難しくなります。
技術的負債は、プロジェクトの納期を守れなくなる主な理由の 1 つです。
時間が経つにつれて、金銭的な負債と同じように増えていくのです。 技術的負債の一般的な原因は、次のとおりです。
- コーディングのスタイルと標準が欠如しています。
- 単体テスト ケースの設計が、欠如しているか不十分です。
- オブジェクト指向の設計原則を無視しているか理解していません。
- クラスとコード ライブラリがモノリシックです。
- テクノロジ、アーキテクチャ、およびアプローチの使用が十分に想定されていませんでした。 (メンテナンス、ユーザー エクスペリエンス、スケーラビリティなどに影響するすべてのシステム属性を考慮する必要があることを忘れています)。
- コードが過剰設計されています (必要のないコードの追加や作成、既存のライブラリで十分な場合のカスタム コードの追加、必要のないレイヤーやコンポーネントの作成)。
- コメントとドキュメントが不十分です。
- 自己文書化コード (説明的な、または意図を示すようなクラス、メソッド、および変数の名前など) が記述されていません。
- 期限に間に合わせるために簡略化しました。
- 実行されないコードが残されています。
Note
時間が経てば、技術的負債は返済しなければなりません。 そうしないと、チームの問題解決や新機能および拡張機能の実装に時間がかかり、最終的にはコスト倒れになってしまうからです。
技術的負債によって開発中に一連の問題が加わり、顧客価値を増やすことがさらに困難になっていることがわかりました。
プロジェクトに技術的負債があると、生産性が低下し、開発チームが苛立ち、コードはわかりにくく脆弱になって、変更と変更の検証に時間がかかるようになります。 計画的な作業に、計画外の作業が頻繁に割り込みます。
長期的には、組織の力が低下します。 技術的負債が、組織に忍び寄って来ています。 それは小規模に始まり、しだいに大きくなっていきます。 急ぎの変更を行ったり、変更を急ぐ必要があるためにテストを割愛したりするたびに、問題はより悪化していきます。 サポート コストがより高くなり、必ず深刻な問題が発生します。
最終的に、組織は顧客のニーズに適時なコスト効率の良い方法で対処できなくなります。
監視のための自動測定
技術的負債の持続的な増加を最小限に抑えるための主要な方法の 1 つは、自動的なテストと評価を使用することです。
この後のデモでは、負債の評価に使用される一般的なツールの 1 つである SonarCloud について説明します。 (元のオンプレミス バージョンは SonarQube でした)。
他にも利用できるツールがあり、そのうちのいくつかについて説明します。
その後、次のハンズオン ラボでは、SonarCloud を使用するように Azure Pipelines を構成する方法、分析結果を理解する方法、最後に、プロジェクトの分析時に SonarCloud によって使用されるルール セットを制御するように品質プロファイルを構成する方法について説明します。
詳細については、SonarCloud のページを参照してください。
確認:
Azure DevOps は、ビルド中にコードの品質をチェックするために使用される、さまざまな既存のツールと統合できます。
現在使用しているコード品質ツールは何ですか (使用している場合)。
そのツールについて気に入っている点または気に入らない点は何ですか。