技術債是什麼、怎麼還？你想知道的都在這一篇文章里了！
前兩周寫了關於技術債務的文章，儘管實踐中會堆積技術債，但這個概念並不在我們的工作中頻繁出現。這篇文章就系統性講講技術債，讓大家避免知其然，不知其所以然。
一、技術債是什麼
技術負債（英語：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，把避免產生技債務作為工作準則，相信不會出現被技術債務壓垮崩潰的情況。
