技術的負債
1. 序章
技術的負債は、チームが時間やコストを節約するために将来リファクタリングされることを意図した、より安価またはより単純なソリューションを使用することを決定したときに発生します。 時々、それらの「後でリファクタリングする」部分が蓄積し、大きな技術的負債をもたらします。 後で、それはプロジェクトに重大な悪影響を与える可能性があります。 さらに、それは非常に危険であり、プロジェクトの成功または失敗について決定することさえあります。 この記事では、技術的負債とその危険性について詳しく説明します。
2. 基礎
言い換えれば、技術的負債は、一時的な解決策となるプロジェクトの部分で構成されています。時間の経過とともに、それらの部分は忘れられるか、非常に多くなり、不可能になります（時間やコストが必要なため）。 ）それらを交換します。 したがって、それらはプロジェクトの弱点でエラーが発生しやすいポイントになります。 どのような状況が技術的負債の増加に寄与する可能性があるかについて、さらに詳しく説明しましょう。
まず第一に、クライアントの決定は技術的負債に影響を与える可能性があります。 たとえば、不正確で急速に変化する要件や厳格な期限により、チームはよりシンプルで迅速なソリューションを使用せざるを得なくなる可能性があります。 これらのソリューションは、非効率的で、面倒で、保守が難しい場合があります。
一方、チームが責任を負う可能性があります。 特にプロジェクトの初期段階になると。 グッドプラクティスの欠如、およびプロジェクトの最初の段階でのリファクタリングは、将来問題になる可能性があります。 その後、プロジェクトは大きくなり、クリーンなコードを維持し、その標準は通常難しくなります。
最後に、迅速な利益に焦点を合わせ、未完成で未完成の製品をリリースし、要件の変更が遅すぎると、技術的負債も増える可能性があります。
全体として、技術的負債にはさまざまな種類と理由があります。 既知の開発者であり著者でもあるMartinFowlerは、技術的負債の象限を定義しています。 それは2つのタイプの技術的負債、すなわち故意と不注意について説明します。 さらに、技術的負債を引き受ける2つのアプローチ、PrudentとRecklessを検討します。 象限がどのように見えるか見てみましょう：
これで、技術的負債が発生する方法と理由がわかりました。 なんでこんなに危険なの？ これについては、次のセクションで説明します。
3. 症状
先に述べたように、技術的負債はプロジェクトに悪影響を与える可能性があります。 状況によっては、プロジェクトの失敗につながることさえあります。 ビジネスの観点から、ソフトウェアの非効率的または不正確な機能は、クライアントとの悪い関係をもたらす可能性があります。
技術的負債の症状は、プロジェクトに関連するさまざまな場所で見られます。 最も重要なレイヤーは、アーキテクチャ、インフラストラクチャ、実装、開発と展開のプロセス、またはチームメンバーのスキルと協力です。技術的負債の症状とその配置を特定することは、それに対処し、将来的にそれを減らすための戦略を計画するのに役立ちます。
まず第一に、アーキテクチャと実装に関しては、特に開発者にとって、症状がはっきりと見えます。 これらには以下が含まれます：
- 読めない、汚れたコード
- 自動テストとテスト環境の欠如
- 非弾性コード
- インコヒーレントなデータモデルとアーキテクチャソリューション
上記の症状は、開発者のアプローチで簡単にわかります。 彼らは、既存のコードを変更してリファクタリングすることを恐れている可能性があります。 さらに、彼らは非常に多くのバグに直面する可能性があります。 最後に、プロジェクトで働く意欲と意欲が低下し、進捗には以前よりも多くの時間が必要になります。
さらに、チーム関連の症状に関しては、最も重要な症状は、一部のチームメンバーの知識やスキルの欠如です。 その後、まれな会議やコミュニケーションの問題も望ましくありません。 さらに、メンバーがいくつかのプロジェクトに取り組んでいると、可用性が制限され、遅延が発生する可能性があります。
最後に、開発プロセスに関しては、次のようなさまざまな段階のさまざまなケースが発生する可能性があります。
- CI /CDインフラストラクチャの欠如
- 不十分なコード品質検証プロセス
- 不十分な要件管理と機能の優先順位付け
- 過小評価されているプロジェクトまたは機能
- バグ修正時間の監視がない
- 不明確なサポートとメンテナンスのプロセス
開発プロセス中のすべての問題は、プロジェクトとその納期およびコストにさまざまな悪影響を与える可能性があります。
4. それを測定する方法は？
技術的負債の規模を見積もる方法は？ 技術的負債を効果的に管理し、継続的に削減できるようにすることは、非常に重要なステップです。 最初は、トピックは複雑に見えます。 ソフトウェアの品質に関しては、保守性の指標、コードカバレッジ、アリティなど、さまざまな変数があります。 まず第一に、監査は技術的負債の影響の一般的な概要を作成するための有用なツールになり得ます。 例として、デューデリジェンスまたはコード品質監査は、リスクと開発の可能性に関する有用なメトリックを提供できます。
ただし、ブロドメトリックが多数あるため、技術的負債を特定して削減するための具体的な計画を作成するのは依然として難しい場合があります。 技術的負債自体の具体的な対策をお願いします。 したがって、比率を使用できます。
開発コストは、プロジェクトを完了するために必要な合計時間数です。 それは多くの方法で見積もることができます。 たとえば、次のように表すことができます。
ここで、 LOC はコードの行数であり、 CPL は1行あたりのコスト（時間単位）です。
さらに、修復コストは、チームに適した任意のコード品質メトリック関数として説明できます。 たとえば、循環的複雑度を使用して時間で表すことができます。
幸いなことに、TDRはSonarQubeなどのツールを使用して自動的に計算できます。 したがって、プロジェクトの開発中にTDRがどのように変化するかを常に確認できます。
5. 債務の支払い
場合によっては、技術的負債が要求される可能性があります。 これは、クレジットによって引き起こされる金融債務と比較することができます。 これにより、組織または製品をより速く成長させ、リードまたはクライアントを獲得することができます。
ただし、遅かれ早かれ、債務を支払う必要があります。 負債が大きければ大きいほど、それはより多くの費用がかかります（関心の高まりのため）。
したがって、技術的負債を特定し、できるだけ早く支払いを開始することが重要です。 多かれ少なかれ、技術的負債を支払うことは、セクション3で述べた症状を軽減することを意味します。 債務を支払うために実行するアクションの例をいくつか定義しましょう。
6. お支払い方法？
まず、コードベースとその弱点に注意する必要があります。 質の高いコードを提供することは重要なタスクです。 したがって、プルリクエストを行う際には、コードレビューを日課として追加することが重要です。 他のチームメンバーがコードをチェックすると、品質が向上するだけでなく、スキルも向上します。
さらに、コード検査とスタイルガイドライン、特に自動化されたガイドラインでは、コードの品質が常に向上します。 その後、ペアプログラミングを時々使用することもできます。
2番目に重要なことはテストです。 これは、さまざまなレベルのソフトウェアにとって有益な場合があります。 コードレベルから始めて、正確さを検証するための単体テストを提供することは必須です。 新しい機能を開発したり、既存の機能を変更したりするときに、ソフトウェアをリグレッションや問題から保護します。 次に、テスト環境と手動テスターを配置することで、本番環境でリリースするまでの機能の検証に役立ちます。
最後に、組織全体に関して実行できる手順があります。 誰もが自分自身と他人の責任を知っている必要があります。 その後、組織内のより明確なコミュニケーションが重要です。 従業員は、どのような場合でも、誰にどのように連絡するかを知っている必要があります。
チームに関して言えば、内部フィードバックは非常に重要です。 チームのメンバー内の問題や競合を解決するのに役立ちます。 次に、変更とリスクを効率的に管理する必要があります。 つまり、すべての休日、チームの変更、またはプロジェクトの変更は、プロセス全体に影響を与えない方法で処理する必要があります。
さらに、会社の安定したビジョンは、各従業員が職場環境で快適で安定していると感じるために重要です。 要約すると、技術的な深さを支払うことは非常に複雑な作業になる可能性があります。 このセクションでは、どこからどのように始めればよいかについていくつかのアイデアを紹介しました。
7. 結論
この記事では、技術的負債について詳しく説明しました。 その基本、症状、および測定について説明しました。 最後に、それを取り除く方法のいくつかの基本的なアイデアについて説明しました。 技術的負債は製品のさまざまなレベルで見られ、重大な悪影響を与える可能性があることがわかります。 したがって、組織は製品の最初から技術的負債を最小限に抑えて回避するように努力する必要があります。
