技術債是什麼、怎麼還？你想知道的都在這一篇文章裡了！

前兩週寫了關於技術債務的文章，儘管實踐中會堆積技術債，但這個概念並不在我們的工作中頻繁出現。這篇文章就係統性講講技術債，讓大家避免知其然，不知其所以然。

一、技術債是什麼

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

1992年，沃德·坎寧安首次將技術的複雜比作為負債。第一次釋出程式碼，就好比借了一筆錢。只要透過不斷重寫來償還債務，小額負債便可以加速開發。但久未償還債務會引發危險。複用馬馬虎虎的程式碼，類似於負債的利息。整個部門有可能因為鬆散的實現，不完全的物件導向的設計或其他諸如此類的負債而陷入窘境。

二、技術債表現

技術債與其他債務本身一樣，是一種透支行為，透過犧牲未來來滿足當下的一些需求。也跟其他債務一樣，技術債務也有利息，而且隨著時間利滾利，會成為埋在專案裡的 雷。如果產品長期的可持續的發展，那麼技術債的重要性是毋庸置疑的。

技術債務的本質是產品的結構阻礙了進步，表現出來的症狀有：無法輕易重構產品以滿足市場需求；元件之間的依賴性過多，體系結構不良；缺陷太多，結構不良；難以理解，難以改變。

技術債務的後果有償還技術債務造成時間浪費，員工滿意度降低帶來士氣低落，因解決遺留程式碼問題而錯過優質專案造成人才流失，產品質量降低造成客戶滿意度下降，技術債務限制創新能力、扼殺創造性等諸多問題。

技術債不單單是技術債，它就像一個垃圾堆，久而久之不處理，慢慢周圍就會產生更多的垃圾，因此產生的“破窗效應”更加是會對未來的專案環境造成很大的影響，大家也會逐漸喪失維護環境的信心。所以在討論技術債的時候不僅僅是討論技術債本身，技術債對團隊追求質量的信心、對大家維護環境整潔的積極性都會造成很大的影響。

Martin Fowler把技術債分為四個象限，如下圖所示：

三、技術債產生的原因

● 業務壓力：為了滿足業務的快速要求，在必要的修改並沒有完成時就匆匆釋出，這些未完成的修改就形成了技術負債。
● 缺少過程和理解：業務人員不清楚不理解技術負債的概念，在決策時就不會考慮到其帶來的影響。
● 模組之間解耦不夠：功能沒有模組化，軟體柔性不夠，不足適應業務變化的要求。
● 缺少配套的自動化測試：導致鼓勵快速而風險很大的“創可貼”式的BUG修復。
● 缺少必要文件：需求和程式碼都沒有必要的支撐性文件或註釋。
● 缺少協作：組織中的知識共享和業務效率較低，或者初級開發者缺少必要的指導。
● 重構延遲：在開發的過程中，某些部分的程式碼會變得難以控制，這時候就需要進行重構，以適應將來的需求變化。重構越是推遲，這些已有的程式碼被使用的越多，形成的技術負債就越多，直到重構完成。
● 不遵循標準或最佳實踐：忽略了已有的業界標準、框架、技術和最佳實踐。
● 缺少相關技能：開發人員有時候技能缺失，並不知道如何編寫優雅的程式碼。

四、如何“還債”？

1.技術債視覺化

儘可能公開技術債，一開始就與團隊，利益相關方一起權衡利弊，並明確告知影響與解決方案。平等溝通，相互理解。讓技術債在業務層面、技術層面可見。

可以在組織資產負債表的財產債中新增兩列：短期技術債和長期技術債。還可以用用跟蹤開發速率的方式體現技術債對於產品的影響。

2.不同的債要對症下藥

技術債的狀態可以分類為偶然技術債、已知技術債和目標技術債。

償還技術債時應遵循如下原則：

1）確定已知技術債必須還。

2）發現偶然技術債，立即還。

3）每個衝刺確定一定數量的已知技術債作為目標技術債，在當前衝刺中償還。

4）無需償還的技術債是行將就木的產品、一次性原型和短命產品。

五、如何避免“欠債”

與其後期吭哧吭哧還債填坑，不如從一開始就儘量避免欠下技術債務。

1.避免使用過時的技術

遺留應用程式、過時的技術以及不同的平臺和流程可能會使組織陷入沉重的技術債務，迫使其推遲基本的現代化計劃。DNS和流量管理技術提供商NS1的聯合創始人兼執行長Kris Beevers說：“技術債務將大量金錢和寶貴的時間浪費在系統和應用程式上，而這些系統和應用程式並不是為現代企業所需的規模和速度而打造的。”
 
舊資產和老方法也往往充斥著安全漏洞，難以整合和自動化，並且很可能不再更新。 Beevers指出：“尋找人才來管理基於複雜或過時的程式碼構建的遺留應用程式也是一個日益嚴峻的難題。堅持採用過時技術不僅會消耗寶貴的預算，而且還會阻礙公司創新和保持競爭力的能力。”

2.參考敏捷實踐

有越來越多的組織漸漸接受敏捷軟體開發，這是將方法交給協作、自行組織的團隊和跨職能團隊的一系列方法和實踐。如果這種方法得到嚴格應用，敏捷開發使組織可以避免技術債務，其方法是快速且以迭代的方式建立和釋出新產品。Dodd說：“這一過程將新產品和新功能儘快並逐步地交到使用者手中。”隨著新版本的交付，各種改進和問題都得到了解決，這使技術債務的積累不太可能產生。
 
敏捷方法認識到專案在生命週期中從未真正完成過，並且也從來都不是完美的。“同時，敏捷方法專注於……針對能力和質量的簡化了的開發”，Dodd說。重要功能往往要頻繁地開發，測試並投入生產。敏捷團隊可能不會發布軟體的“全面（Big Bang）”方法，而是每年釋出幾次重大升級。Dodd指出：“這可以使產品保持相當平穩的發展，還可以幫助使用者避免重大的中斷事件。”

3.遵循程式碼規範

是否遵守了編碼規範，是否遵循最佳實踐也是影響技術債的一個方面。程式碼規範在研發專案團隊中有著重要作用，團隊統一程式碼規範，有助於提升程式碼可讀性以及工作效率。統一的
程式碼規範是程式碼集體所有權的基礎，會讓結對程式設計更容易實行，對團隊來說更易內部輪崗、獲得晉升。程式碼規範和程式碼質量工具有助於發現程式碼質量方面的技術債務。

亡羊補牢，為時未晚。從現在開始把償還技術債務納入backlog，把避免產生技債務作為工作準則，相信不會出現被技術債務壓垮崩潰的情況。