【51CTO.com快譯】通常而言，債務是一個能夠讓人產生消極感覺的詞彙。大家往往會聯想到學生貸、醫療費、以及抵押付款等景象。不過，一些金融上的債務還是多少對人有益的。而技術債也是如此。
作為一個隱喻，技術債(也稱為代碼債務)是指開發團隊為了加快項目或功能的交付速度，在後期需要重構時會發生的情況。顯然，優先事項是更快的開發過程，而不是更高質量的代碼。
和金融債務類似，技術債對於組織來說是一把雙刃劍。為了合理地使用它，工程師和團隊負責人必須監控他們手頭有多少技術債，並學習如何對其進行良好的管理。而對於組織而言，這將是一項艱巨的任務，尤其是當他們對技術債的優缺點尚不清楚時。
技術債的基本特徵
Scrum已經成為了軟體開發人員在尋求以更高效的方式交付產品時，使用到的流行框架。眾所周知，客戶經常會有新的需求出現，並且會改變主意。因此，開放性的Scrum以事情的不可預測性為重要原則，並讓用戶在使用該框架時產生技術債。
在此，我們借用Scrum培訓師Stefan Wolpers(請參見--https://www.scrum.org/resources/blog/technical-debt-scrum-who-responsible#:~:text=%E2%80%9CTechnical%20debt%20(also%20known%20as,approach%20that%20would%20take%20longer.%E2%80%9D)曾經提到過的，如下兩種不同類型的Scrum技術債：
首先創建一個由性能欠佳的代碼所組成的短期解決方案，以便開發團隊可以更快地交付產品。同時，團隊期望在初次發布之後，回過頭來改善代碼的質量。
隨著開發團隊發現有關待解決問題信息的增多，另一類技術債也會被動地產生。即：隨著新需求的出現，往日起作用的解決方案可能在將來就失效了。因此，這些需要調整和重構的代碼，會包含一定數量的債務。
Wolper同時認為：Scrum團隊應該重視如下方面：
為了簡便管理，應優先考慮技術債的透明度。團隊需要將技術債的可視化突顯效果放在首位，並在每次Sprint(衝刺)會議期間審查技術債的各項需求。
跟蹤技術債。團隊通過儘可能地使用諸如圈複雜度(cyclomatic complexity)、代碼覆蓋率、SQALE評級、以及違反規則等深入的代碼度量標準，對各類錯誤進行記錄和計數。
快速定期償還債務。Scrum團隊應該考慮在每個Sprint周期中，將其15-20%的資源分配給重構代碼並修復錯誤。
調整產品的積壓，將其與償還的技術債任務關聯。您可以將債務整理成要解決的Sprint狀態，以有助於防止債務被遺忘。
調整對「完成」的定義，即：在滿足了那些可管理的技術債的既定標準之前，請不要將其狀態設置為完成。
規範程序。為團隊如何處理添加新的功能(包括引入技術債)，制定可重複的公式。
技術債有哪些不同類型?
目前，大多數專家普遍認為技術債有故意和無意的兩種類型。其中：
當組織為了縮短上市時間而選擇留出改進代碼的空間時，就會產生故意的(也稱為主動)技術債。
當在發布了一段時間create後需要提高代碼的質量時，就會產生無意的(也稱為偶然的、過時的、被動的)技術債。這些既可能是由於第一次發布不佳所致，也可能是由於代碼過時而自然產生的更新需求。
另一種觀點則根據技術的具體類別，以及組織預期的更好服務，提出了如下13種不同類型的技術債，每一種債務都包含了標題中的特定問題：
建築債務
構建債務
代碼債務
缺陷債務
設計債務
文件債務
基礎設施債務
人員債務
處理債務
需求債務
服務債務
測試自動化債務
測試債務
Martin Fowler在故意和無意的分類基礎上增加了魯莽和謹慎兩個維度，提出了技術債的四象限。其中謹慎的技術債來自一個知道如何做的團隊，而當人們太草率時，魯莽的債務就會產生。兩者的區別在於：審慎的團隊是在了解其行為的基礎上，故意地去使用技術債。而魯莽的團隊則像是剛剛經歷了雙十一剁手節一樣，碰到債務的不斷增加。
可見，對於所有的軟體工程團隊而言，無論他們的專業知識或經驗如何，適當承擔一定程度的債務是可以接受的。也就是說，在謹慎的情況下，一些可以預期的債務會促進團隊知曉應當對手頭的項目做些什麼，以及哪些是稍後要進行的一些新工作。他們不但會盡力減少魯莽的債務，還能減少不良代碼，以提高軟體的質量。
應當始終避免哪種類型的技術債?
審慎的技術債雖然對軟體組織來說有一定的好處，但是如果累積得多了，從量變發生了質變，也可能會成為魯莽的技術債。也就是說，當軟體隨著時間的流逝，惡化到產生錯誤、甚至影響其功能和可用性時，就會成為Bit rot(也稱為「軟體熵」)。例如：當開發人員需要對其不甚了解的歷史遺留代碼進行較小的增量更改時，軟體本身的複雜性和潛在問題會隨即增加。一些工程師甚至可能違反NFR(Non-functional requirement，非功能要求)，完全破壞代碼，進而對軟體的整體功能產生影響。解決此類技術債的唯一方法便是重構整個過程。
而且，在大多數情況下，團隊並不會察覺到自己的一些微小變化，實際上會導致債務總額的增加。雖然我們也可以使用Wolper的透明化概念，協助避免此類災難的發生，但是從根本上說，團隊還是應當對目標軟體具有充分的了解，從而避免在無意中添加可能阻礙系統的代碼。
技術債的指標有哪些?
和任何良好的管理計劃類似，組織需要通過了解各項指標，才能獲得對於技術債的控制權。下面是一些值得參考與衡量的指標：
軟體缺陷
軟體開發者應當持續記錄和跟蹤發現到的缺陷，其中包括未修復的缺陷和已修復的缺陷。對於未修復的缺陷，開發團隊可以在敏捷迭代中持續專注和修復它們。而通過跟蹤已修復的缺陷，團隊則能夠衡量其技術債的管理流程與效率。
代碼質量
如果說軟體缺陷直接影響的是軟體的最終用戶，那麼代碼的複雜性則會阻礙團隊的開發與維護。下面是有關代碼複雜度的指標：
圈複雜度
類的耦合
代碼行數
繼承的深度
當然，這些指標應該越低越好。通過密切關注這些指標，團隊還能夠準確地獲悉有待重寫或重構的代碼，以降低複雜性，並改善軟體的後端。
代碼的內聚
與代碼質量類似，專注代碼的內聚性，將有助於簡化代碼的複雜性。較高的代碼內聚性通常意味著目標代碼更具有可維護性、可重用性和魯棒性。同時，該指標還可以最大程度地減少需要開發人員的數量，以及大幅降低複雜性，減少Bit rot。
代碼所有權
「人多手雜」在此可以被用來形容更多的開發人員，產生更多的工作量，導致更大的問題，以及更多的無意技術債。因此，我們需要祭出「代碼所有權」的指標，來解答「誰在關注哪塊代碼?」，以及「如果出現問題該找誰?」等問題。
此類指標將向項目管理人員展示從事某項代碼工作的人員數量，以及花費在控制上的時間。據此，我們可以避免由於完整的代碼部分被掌握在某個成員手裡，而他可能因為被堵在路上，而耽誤了項目進度等單點故障。因此，我們可以將代碼庫分割成不同的域，然後授權給團隊中不同的開發人員角色。
代碼變化(Churn)
代碼段被重寫或替換等活動都可以被視為發生了代碼變化。如果開發人員不得不圍繞著某段代碼持續解決相似的錯誤，那麼就意味著此處的技術債非常嚴重。據此，團隊也可以識別並確定代碼的哪些部分需要重構。因此，團隊需要特別注意那些經常發生變化的代碼，以便快速發現問題，進而避免問題的加劇和技術債的累積。
值得一提的是，簡單地跟蹤上述技術債的各項指標，並不能自動消除所有的債務，我們仍然需要更為有效的管理實踐。
有關技術債的調查
根據卡內基梅隆大學軟體工程學院的一項行業調查(請參見--https://insights.sei.cmu.edu/sei_blog/2015/07/a-field-study-of-technical-debt.html)發現：糟糕的架構往往是技術債的首要來源，其次是過於複雜的代碼，第三則是缺少文檔和測試之間的緊密聯繫。而更糟糕的是，有65%的受訪者表示他們沒有適當的技術債管理應用。這就意味著由於缺乏策略來應對技術債，因此他們選擇不去實施任何解決方案!
一位擁有與多家公司(從《財富》500強到初創公司)合作超過20年經驗的軟體開發人員建議：開發團隊應當像投資信用卡業務那樣去投資技術債，而且投資的重點應放在如下兩個地方：
公司的文化，將人員對應到複雜的系統上，各司其職。
代碼庫的構建，執行更深入和更頻繁的質量保障測試。在組織已經積累了大量技術債的情況下，您可以將此類測試自動化。投資的內容至少涉及到通過某種形式的代碼審查，以確保問題能夠被儘早地解決。當然，這也意味著需要更加頻繁地進行重構。
不過，上述兩方面的投資只是一個起點，我們仍然強調需要管理自己的技術債。如果沒有一個明確的策略，技術債會繼續增加，並在線上和線下製造更多的問題，正如上述調查中所提到的那樣。
如何管理技術債?
就像金融債務一樣，只有通過制定計劃，實施管理，才能減少技術債。當然，正所謂「知易行難」，我們真正管理起來並不容易。它需要持續的監控和投入，並將其納入軟體開發的必要組成部分。而且，由於技術債很容易脫離業務目標，因此對其管理有助於讓開發與業務目標保持一致。
據預測，到2024年，技術債務將給全球科技公司帶來4萬億美元的損失。而實施了技術債管理與補救的公司將會縮短50%客戶產品交付時間。
目前，市場上已有一些新的技術應用捕捉到了此類軟體需求，並提出了相應的解決方案。例如，Stepsize之類的軟體，便可以使開發團隊輕鬆地獲取債務報告，對它們進行分類，並確定有待解決的最重要債務。通過監控並管理積累的所有技術債，它們可以協助軟體工程團隊在無需大幅改變常規工作流程的前提下，及時交付出色的軟體產品。
原文標題：The Engineer’s Complete Guide to Technical Debt，作者：Alex Omeyer
【51CTO譯稿，合作站點轉載請註明原文譯者和出處為51CTO.com】