Hi all，最近在台北敗了幾本書籍來看，抱持著 "想到就看，看了就更新"的心態於是有了此系列筆記。

閱讀書籍

技術債 ( Technical debt )

• 一種軟體技術名詞
• 開發人員必須對技術債有相當的理解，才能知道其對於往後的影響有多大。

定義

技術債是有意或無意中作出錯誤或非最佳的設計決策所引起的債務

舉個例子🌰： 當我們使用信用卡時，便會欠下卡債。如果定期之後卡債則債務就得到了償還，不會產生進一步的問題。但今天我們若不支付卡債則必須承擔罰息的部分，且卡債也不會因此而變小。若我們長期欠繳，產生的帳單或是罰單壓得我們喘不過氣，最後只能導致我們不得不宣告破產。
同樣地，當開發人員選擇了當下最適合的計畫而非設計良好的方案，便會欠下了所謂的技術債。經由技術債的不斷累積，在最後債多到無力償還，只能宣告放棄該產品，在書中稱之為 技術破產 (technical bankruptcy)。

分類

技術債的分類種好幾種，書中整理了一些著名的技術債維度及範例

• 程式債務：不一致的撰寫風格
• 設計債務：設計臭味及違反設計規則
• 測試債務：測試案例不充實，測試涵蓋率不足及測試設計不合理
• 文件債務：缺乏重點方面的文件、文件劣質、過期文件

bug 算不算是技術債呢？

有兩種派別說法

• 導致缺陷的根源是技術債，因此缺陷屬於技術債
• 有些業界人士提出 缺陷和技術債的主要差別在於，缺陷對用戶來說是可見的，而技術債通常來說是不可見的。（書上推崇此想法）

技術債影響的範圍是軟體系統內在的品質，而內在品質不是用戶可以直接感受得到的。而真正影響用戶的是外在品質，因此公司通常注重於修部缺陷而非償還技術債。
綜合上述，以現實角度來看，最好是別把缺陷與技術債混為一談，這樣便可單獨的解決他們。

因素

讓軟體系統欠下技術債的是 PM/PO 或是開發人員的決策。問題來了，為什麼會下這種會欠債的決策呢？書上提出了幾點引發技術債的常見原因：

• 時間緊迫
• 缺乏優秀/經驗豐富的設計人員
• 未遵循設計原則
• 不懂設計臭味和重構

暫時欠下一些技術債是可以接受的，但儘早償還這些債務也是非常重要的

管理

欠下技術債是不可避免的，但我們可以對其進行管理，以下書中整理了以下的步驟

1. 增強技術債意識：了解技術債的概念、各種形式、影響以及導致技術債的原因。
2. 發現並償還技術債：確定欠下的技術債規模。找出具體技術債並確定其影像。
3. 防範技術債累積：技術債得到控制後，必須採取預防措施。