在1992年Ward Cunningham在博客中提出技術債這個概念後，技術債這個比喻因完美地表達了遺留技術問題的影響，被一直沿用至今，且一直是行業內關注的焦點。如今各大企業爲了建立持續交付的能力，快速響應市場的變化，也紛紛開始提升研發效能，技術債更是不可忽視的關鍵因素。
技術債的分類
（圖片源自MartinFowler的博客：TechnicalDebtQuadrant）
按照技術債產生的原因，Martin Fowler將技術債按照 魯莽的（Reckless）/謹慎的（Prudent） 以及 故意的（Deliberate）/無心的（Inadvertent） 劃分到4個不同的象限中。我們分別來解釋下這幾種不同的技術債：
1. 謹慎的 且 故意的
這種場景很常見，是已知技術債的一種主要來源。爲了讓產品快速投入市場，獲得更大的收益，通常團隊會選擇更快速的方案，開發成本低，時長短，但解決方案並不是最優，且可能只是臨時方案。然而，團隊對技術選擇做了詳盡的評估，瞭解技術債產生後給產品和架構會帶來什麼影響，後果是可估量的，甚至已經安排好了未來的改進計劃。
2. 魯莽的 且 故意的
相比上一個分類而言，團隊知道當前的方案不是最優選擇，但通常由於時間緊迫，實現當前的業務需求是第一優先級的，未對當前的方案做細緻的分析，因此對遺留技術債可能產生的影響是未知的，甚至具體產生了哪些問題也可能是未知的。
3. 魯莽的 且 無心的
不計後果而又是無心之舉，這往往是因爲團隊成員的認知還不足以判斷當前的選擇是不是會帶來不良影響。這種技術債在技術債總體的佔比很高，甚至可能比上面提到的第一種技術債更多。因爲不管怎樣的團隊，人員的更替都是避免不了的，個人的經驗不同，認知不同，在實現相同的功能時選擇的方案也是不同的，雖然可以通過一些社交活動來減少不同團隊成員的認知差異，如代碼評審，但想通過這種方式來避免技術債的產生，效果往往並不是很好。
4. 謹慎的 且 無心的
這種技術債看上去讓人難以理解，既然每次都是深思熟慮，爲什麼還會有無心之失。然而，這種技術債確實也是無法避免的，甚至會經常遇到，最簡單的莫過於當下基於當下的經驗甚至業界最優的一些實踐選擇的技術方案或者技術框架，而隨着技術的進步和發展，它們的弊端和問題也會逐漸顯現出來，這些過時的技術方案設計和框架也就成了技術債。
技術債的影響
不管是上面的何種原因，技術債一旦產生，都會對軟件系統產生或大或小的影響。技術債涉及到的具體內容也非常廣泛，一切不合理的設計或妥協都可以稱之爲技術債，比如：
- 因認知不足或成本原因而產生的不良架構設計或代碼設計
- 因能力或認知不足而選擇非最優的技術框架或選型
- 因成本或進度原因而沒有完成的測試代碼
這些技術債短期都不會表現出明顯的問題，但在項目長期迭代過程中，隨着技術債不斷的增加，軟件系統的可維護性會直線下降，隨之而來的是質量的下滑，這給後續的產品開發帶來了非常大的問題。
1. 產品質量下降，生產事故頻發
這是最大最直接的影響，當技術債不斷增加，軟件系統會變得非常脆弱。這種脆弱主要是由不良的架構設計或代碼設計導致，不管最初是選擇了劃分良好的微服務架構，還是單體架構，技術債不斷打破設計原則，讓原則不復存在，軟件系統都將走向大泥球，沒有人能理得清系統組件之間的關係和職責。當修改其中的一部分組件時，其他組件莫名奇妙受到影響，而且這種情況通常只有上線之後纔會被發現，整個團隊將陷入不斷救火的循環中。
2. 系統可維護性差，開發效率低下
一個軟件產品如果在5-10年後依然還能很好的響應市場的變化，說明軟件的設計也在逐漸演進，還具有很強的生命力。相反，很多軟件在經過幾年的開發之後，隨着技術債的增加，已經變得不可維護，大部分情況下只能被推倒重寫。
這種不可維護都可以歸功於不斷疊加的技術債，技術債的疊加不斷增加系統的複雜性。在這些技術債沒有解決之前，開發的成本逐漸增高，每次變更都需要解決不良的設計或落後的技術選型所帶來的問題。
舉個例子，一個簡單的業務需求實現在設計有缺陷的軟件架構上，修改已存在的複雜邏輯還不如重寫來的簡單，相信很多人曾有過這種感覺。重寫只需要理解新需求就可以了，而修改需要理解舊的實現，找到新舊之間的差異。重寫可以直接採用較優化的方案，而修改可能在已有技術債的基礎上，要麼解決技術債的問題，要麼找出一個繞行的方案，實現成本通常是更高的。
如何避免和解決技術債
理解了上面技術債產生的原因，就知道想要徹底避免技術債的產生是不可能的。產品在演進，技術在更新，代碼一旦寫出來就需要花費額外的成本來維護，再加上團隊人員的變化，上下文的丟失，很難做到時時保持系統在100%健康的狀態。
然而，我們卻可以根據技術債產生的原因，來分析如何避免和解決技術債。魯莽的/謹慎的 可以理解在技術債產生時，團隊是否做出來細緻的分析，其結果可以對應到 無解決方案/有解決方案。而 故意的/無心的 表達的是對於技術債的產生是已知的，還是未知的，可以對應到 已知問題/未知問題。這樣就可以將問題的解決也同樣劃到四個不同的象限。
對於第一象限而言，已知問題，也有解決方案，只需要將技術債的解決列入計劃實施起來就可以了。而對於其他象限，都無法直接列入計劃解決，因此，我們需要通過一些手段讓技術債從認知和方案層面向第一象限移動。第三象限的技術債，團隊認知水平很低，只能通過提升團隊的整體能力和認知水平，讓問題逐漸清晰，向第二和第四象限轉移。爲了儘快解決團隊內的技術債，可以嘗試以下幾點：
1. 技術債解決日常化
研發團隊對於架構的守護要像產品人員對待產品一樣，架構健康和產品質量一樣重要。在項目日常開發中，除了產品的業務需求外，應該規劃一部分工作用於架構的優化，修復那些已知且有解決方案的技術債，這樣才能持續保證軟件系統的響應能力和產品質量。
2. 明確技術規範，加強管理
對於已知且無解決方案的問題，只是沒有深入思考對系統的影響，對於這部分技術債，產生的原因主要有兩個：
- 團隊沒有技術規範標準，即便發現問題，也沒有方案
- 缺少對架構修改的審查，開發人員自己思考解決方案，依賴個人經驗
爲了讓這些技術債在產生前就避免，或者引導到可以快速解決的方向，首先，需要建立團隊的技術規範和標準，讓每個決策都有依據。其次，加強流程上的管理，建立架構評審委員會，對架構的修改進行評審，一方面規避問題，另一方面根據問題完善規範和標準。
在Neal Ford、 Rebecca Parsons 的著作《演進式架構》中提出了“架構適應度函數”（Architecture Fitness Function）的概念，當團隊有了技術規範和標準，可以通過構建架構適應度函數，來檢查和約束架構的變更或代碼的修改，幫助我們發現和避免一些新技術債的產生。
3. 持續關注技術發展趨勢，提前規劃架構的演進方向
隨着技術的不斷髮展，很多幾年前被認爲非常先進的技術表現出了一些弊端，也逐漸在被新的技術替代。研發團隊需要持續保持對技術發展趨勢的關注，探索是否有更優的解決方案，在日常的開發和運維過程中，要做到以下幾點：
- 明確當前團隊的技術選型優勢和問題，深入理解團隊面臨的問題
- 對於所選擇的技術框架版本持續關注，定期升級到最新的穩定版本
- 關注新技術的趨勢和動向，探索是否有更優的解決方案，新的技術是否經過成熟的驗證，提前規劃架構的演進方向
關注新技術不代表一味追求新技術，首先要明確現有的技術選型到底有哪些解決不了的問題，而在選擇新技術的時候也要思考它的弊端在哪裏，是否有很大的影響。
4. 技術債可視化
通常可視化是一個非常快速能幫助團隊發現問題以及強調問題的最直接的辦法，任何言語也無法媲美視覺的衝擊。但要注意的事，技術債粒度可大可小，優先級也各有不同，並不是所有的技術債都需要立即修復，技術債的產生在某些情況下就是爲了快速的追求產品的市場價值而存在的，需要不斷的權衡。
團隊需要將識別到技術債時及時可視化出來，判斷技術債所處的象限，判定優先級，通過內部流程將技術債的狀態進行轉移，進而可以通過上面的方法進行解決。
5. 保持技術優化相關投入
這個建議更多是給團隊的高層管理者，在激烈的市場競爭中，產品的開發可謂爭分多秒，管理者們一定更願意花錢在看得見的產品上。一旦技術框架基礎已經奠定，會逐漸縮減在技術側的投入，這其實也是大部分產品的軟件系統技術債逐漸增多的一個非常重要的原因，產品的快速演進，進度的壓力無疑是技術債產生的最大元兇。
爲了保證產品持續的競爭力，上面幾點只是方法，如果沒有成本上的投入，只能淪爲空談。從整個產品團隊，都要提升對技術的正確理解，技術的構建並不是一勞永逸的，是需要不斷的成本投入來維護的。
更多閱讀
文/Thoughtworks 麻廣廣
原文鏈接：如何解決技術債