Managing Technical Debt: Reducing Friction in Software Development I-1

2024年6月5日

https://learning.oreilly.com/library/view/managing-technical-debt/9780135646052/

Part I: Exploring the Technical Debt Landscape
Chapter 1. Friction in Software Development

技術的負債（technical debt ）という言葉
ウォード・カニンガム
1992年
機能する高品質なソフトウェアを提供するためのスピードと手直しの微妙なバランスを伝えるためにこの言葉を導入した。

Becker and colleagues
2015年
技術的負債を「情報、システム、インフラの寿命と、周囲の状況の変化に伴う適切な進化」と表現

多くは、技術的負債を、内部的なコード品質の低さを示す、やや回避的な用語とみなしている。
部分的にしか正しくない。
技術的負債が本質的なコード品質とはあまり関係がなく、時間をかけて実施された設計戦略によるものであることが多いことを示す。
技術的負債は、たとえ優れたコード品質を持つシステムであっても、全体的なシステム設計やシステム・アーキテクチャのレベルで発生する可能性がある。
また、システムの設計者や実装者のコントロールの及ばない外部の出来事から生じることもある。

技術的負債の定義
ソフトウェア集約型システムにおいて、技術的負債は、短期的には好都合であるが、将来の変更をよりコスト高にしたり、不可能にしたりするような技術的背景を設定するような設計や実装の構造から構成される。
技術的負債は偶発的負債であり、その影響はシステム内部の品質に限定される。

技術的負債の例
Quick-and-Dirty if-then-else
Hitting the Wall
Crumbling Under the Load
Death by a Thousand Cuts
Tactical Investment
各例題が思い当たって勉強になる

TDMM：技術的負債成熟度モデル

技術的負債管理の原則
原則1：技術的負債は抽象的な概念を再定義する。
原則2：利息が発生しないのであれば、技術的負債を負っていない可能性が高い。
原則3：すべてのシステムには技術的負債がある。
原則4：技術的負債はシステムをトレースしなければならない。
原則5：技術的負債は悪い品質と同義ではない。
原則6：アーキテクチャの技術的負債は、所有コストが最も高い。
原則7：すべてのコードが重要
原則8：技術的負債には、元本にも利息にも絶対的な尺度がない。
原則9：技術的負債はシステムの将来の進化に依存する。