重構 (Refactoring) 學習心得筆記 - 技術債 (Technical Debt)

文章最後更新於 2021 年 2 月 11 日

內容目錄

技術債 – Technical debt 是什麼？

技術負債（英語：Technical debt），又譯技術債，也稱為設計負債（design debt）、程式碼負債（code debt），是程式設計及軟體工程中的一個比喻。指開發人員為了加速軟體開發，在應該採用最佳方案時進行了妥協，改用了短期內能加速軟體開發的方案，從而在未來給自己帶來的額外開發負擔。這種技術上的選擇，就像一筆債務一樣，雖然眼前看起來可以得到好處，但必須在未來償還。軟體工程師必須付出額外的時間和精力持續修復之前的妥協所造成的問題及副作用，或是進行重構，把架構改善為最佳實作方式。

1992年，沃德·坎寧安 (Ward Cunningham)首次將技術的複雜比作為負債。

想想看，在專案的一開始，每個人都盡全力的寫出最好的程式碼，怎麼會有人故意寫一些不乾淨的程式碼，造成專案未來負擔？是什麼時候開始程式碼變的不乾淨呢？

技術債的分類

馬丁·福勒提出了把技術債分為四個象限

	魯莽Reckless	謹慎Prudent
故意Deliberate	我們沒有時間做設計	我們必須馬上交付，後果以後再說
疏忽Inadvertent	什麼是分層（設計）？	現在我們才知道該如何做了

導致技術債形成的原因

簡單來說，就是：能力不足，意願不足，資源（時間）不足

下列是一些常導致技術債形成的原因：

商務壓力、時程壓力 (Business pressure)

有時候專案時程就是很趕，必需要能及時上線，「先求有，再求好」之類的話就出現了。通常在這種情況下，就會用一些所謂的「Quick Solution」來達成一些功能(Features)，可能連測試都先略過不寫，技術債因此產生。

缺乏對技術債產生的後果的了解 ( Lack of understanding of the consequences of technical debt)

有時就老闆不了解技術債是會產生”利息”的，隨著技術債的累積，會漸漸的拖慢了專案發產的速度，當管理階層不了解重構的價值時，是很難去要求開發團隊把時間花在做程式重構的工夫上的。(Boss: 功能正常可以動就好啦，不要再去改了，新功能開始進行開發了嗎？)

無法對抗緊耦合、層層關聯的組件 (Failing to combat the strict coherence of components)

這像專案是一大塊的巨石或是俗稱的大泥球，而不是一個一個獨立的模組所組成，功能不是模組化，軟體不夠靈活應對商務上的變化，更改一部分的程式會影響到其他部分，在開發上很難獨立開來處理。

缺乏測試 (Lack of tests)

缺乏自動化的測試能即時反應問題或是bug，導致程式上線時，問題或bug一發生，工程師會緊急使用一些高風險的workarounds去解決，在最壞的情況下，這些沒事先測試的程式就會部署到Production中，後果可能會是個更大的災難。舉例來說，沒有預先測試的保護下，一個小小的hotfix可能造成程式寄了奇怪的email給客戶，或是不小心把整個資料庫刪了。