開發工程師技術債務的完整指南

債務是一個複雜的話題。而軟體開發工程師需要了解什麼是技術債務以及如何有效管理技術債務以加速軟體開發過程。

債務這個術語經常帶有負面含義，而一提到債務，在人們腦海中經常會浮現貸款、醫療賬單以及抵押貸款這樣的景象。但實際上，一些金融債務實際上可以為人們提供幫助。

技術債務也是如此。技術債務(也稱之為代碼債務)是指開發團隊加快傳遞今後可能需要重構的項目或功能時會發生的情況。對于開發團隊來說，加快開發過程成為優先事項，而不是高品質的代碼。

與金融債務一樣，技術債務可能會為組織帶來損害或可能提供幫助。為了明智地使用，軟體工程師和團隊上司者必須了解有多少技術債務并學會妥善管理。對于組織來說，這可能成為一項艱巨的任務，尤其是當他們對技術債務的利弊沒有明确了解的時候。

技術債務是一個隐喻性架構，可以用于思考在開發團隊加快軟體生産之後需要重構的細節。

技術債務有哪些同義詞?

像大多數創造出來的術語一樣，技術債務還有很多其他名稱，它們基本上都意味着同一件事情。在談論技術債務時，人們可能還會看到諸如……

• 技術債務(Tech debt)：技術債務的簡寫或昵稱。
• 設計債務：與軟體的設計元素有關的技術債務。
• 代碼債務：與程式員必須重構的軟體系統中的不良代碼相關的技術債務。

這些術語都有細微的差别，但都屬于更大的技術債務類别。

如何在Scrum架構中使用技術債務以及如何處理它

Scrum如今已經成為軟體開發人員在尋求以更有效的方式傳遞産品時使用的流行架構。Scrum的一個關鍵原則是事情是不可預測的：客戶改變主意或經常出現新需求。這種對變化的開放，意味着組織在使用Scrum架構時可能會出現技術債務。

Scrum教育訓練師Stefan Wolpers對Scrum中兩種不同類型的技術債務進行了分析與闡述。

• 首先是主動選擇建立由不完美代碼組成的短期解決方案，以便可以更快地傳遞産品。期望開發團隊會在初始釋出之後并不斷來改進代碼品質。
• 當開發團隊發現有關他們試圖解決的問題的更多資訊時，另一種類型的技術債務可能會出現。随着新需求的出現，以往有效的解決方案如今可能無法奏效。其代碼需要調整和重構，這樣就産生了一些技術債務。

Wolpers指出，Scrum指南并沒有給出任何關于如何減少技術債務的具體指導。正如他所說，Scrum指南并沒有提供萬能的解決方案。盡管如此，他也認識到技術債務的積累是組織在開展業務時不可避免的一部分，并為Scrum團隊來更好地處理他們基于代碼的技術債務提供了六種方法。

他說，Scrum團隊應該：

(1)優先考慮技術債務的透明度。Wolpers表示，透明度使管理技術債務變得更加簡單。他建議開發團隊突出展示他們的技術債務的可視化，将其作為首要任務，并在每次召開的Sprint會議期間審查他們的技術債務需求。

(2)跟蹤技術債務。Wolpers建議對錯誤進行計數，并盡可能使用更深入的代碼名額，如圈複雜度、代碼覆寫率、SQALE評級以及規則。

(3)快速、定期地償還債務。與金融債務一樣，當團隊定期償還時，技術債務就會得到更好的管理。Wolpers表示，Scrum團隊應該考慮将15%～20%的資源配置設定給每個Sprint周期的重構代碼和修複錯誤。

(4)減少産品積壓。組織的産品積壓應該包括與償還技術債務相關的任務。而組織将這些債務列入想要解決的問題，将有助于防止債務被忽視或遺忘。

(5)調整對“完成”的定義。在達到可管理的技術債務的既定标準之前，不要将某事視為已經完成。

(6)規範程式。為組織的團隊如何處理添加實驗或新功能(包括引入技術債務)制定一個可重複的公式。

技術債務有哪些不同類型?

技術債務可以采取許多不同的形式，但還有很多人對于這些差異進行讨論。

而大多數專家都認同具有兩種不同類型的技術債務：有意的和無意的。而這與Wolper将Scrum使用者的主動和被動技術債務進行分離有些類似。

當組織為了縮短上市時間而選擇在其代碼中留出改進空間時，就會發生有意的技術債務(也稱為故意或主動)。

當代碼品質在一段時間後需要改進時，就會發生無意的技術債務(也稱為偶然的、過時的、被動的或無意的)。這可能是第一次生産不佳的結果，或者隻是随着代碼過時而自然需要更新。

2014年發表的一篇名為《走向技術債務本體論》的學術論文對于隻有兩種類型的技術債務的觀點進行了反駁。該論文指出，如果技術債務有更具體的類别，組織将會得到更好的服務，是以論文提出了13種不同類型的技術債務，每種類型都包括這篇論文指出的具體問題：

• 架構債務
• 積累債務
• 代碼債務
• 缺陷債務
• 設計債務
• 檔案債務
• 基礎設施債務
• 人員債務
• 處理債務
• 要求債務
• 服務債務
• 測試自動化債務
• 測試債務

雖然這些債務分類方法還有其他細節，但最流行的債務分類方法來自Martin Fowler的技術債務象限。與Ward Cunningham一樣，Martin Fowler是靈活軟體開發宣言的17位作者之一。然而當談到技術債務時，Fowler獨自開發了他所謂的“技術債務象限”。

Martin Fowler的技術債務象限是什麼?

2009年，Fowler對由Steve McConnel推廣的有意和無意的技術債務的雙重分離進行了細微的修改。他認為人們用債務進行比喻就像是問錯了問題。

Fowler并沒有試圖找出有關設計缺陷的技術問題的答案，例如“這是否被視為技術債務?”，而是想知道這些軟體系統産生的債務是魯莽的還是謹慎的。這種差別，再加上“有意”或“無意”債務的概念，形成了Fowler所稱的技術債務象限。

這個象限産生四種不同類型的技術債務：

• 魯莽和有意。
• 魯莽和無意。
• 謹慎和有意。
• 謹慎和無意。

有意債務發生在創造的選擇中，無意債務發生在團隊需要做出調整之後。然而，謹慎債務和魯莽債務的差別更加獨特，這種分類賦予了技術債務象限的價值。謹慎的技術債務來自一個知道自己在做什麼的團隊，而當他們做事過于草率時，就會産生魯莽的債務。

能看出謹慎和魯莽的差別嗎?

謹慎的團隊了解他們的舉動，并且他們有意使用他們的技術債務。

魯莽的團隊隻是将他們的軟體系統視為瘋狂購物的美國運通銀行持卡人，将導緻技術債務不斷地積累。

Fowler指出，用債務比喻來解釋象限中最複雜的部分是謹慎和無意部分。而當一個團隊知道他們在做什麼并且在項目上做得很好但最終仍然需要一些返工時，就會出現這種情況。

Fowler表示，無論團隊的專業知識或經驗如何，軟體工程團隊都應該承擔一定程度的債務。在謹慎的情況下出現少量債務是可以預料的，但這隻會使減少魯莽債務并盡可能減少不良代碼而變得更加有價值。

應該始終避免哪種類型的技術債務?

謹慎的技術債務可以為軟體開發組織帶來很多好處，但這些組織應該密切關注他們積累了多少技術債務。魯莽從來都不是好事，但存在另一種可能對組織造成更大傷害的技術債務：位衰減(bit rot)。

位衰減(也稱為“資料腐化”)發生在軟體随着時間的推移而退化到産生錯誤甚至改變其功能和可用性的程度時。位衰減需要一些時間來開發，但它将讓開發團隊更加謹慎。

當開發人員對他們不完全了解的遺留代碼進行增量的微小更改時，通常會發生這種情況。這些微小的更改最終會造成足夠的複雜性和問題，進而影響整個軟體的。一些軟體開發工程師甚至可能違反非功能性要求(NFR)或完全破壞代碼。解決這種技術債務的唯一方法是重構整個系統。

而技術債務面臨最大的問題是，微小的變化實際上會增加債務總額，而且開發團隊在大多數時候甚至不知道這一點。使用Wolper的透明度概念可以幫助組織避免這樣的災難。

同樣，開發團隊将從完全了解他們工作的每個軟體中受益，這樣他們就不會無意中添加可能阻礙系統運作的代碼。項目管理團隊可以通過確定他們的開發過程不會留下發生位衰減的空間來讓他們的開發人員負責。

什麼是技術債務名額?

除非能夠衡量它，否則了解很多關于技術債務的知識并不重要。

但是應該衡量什麼? 與任何良好的管理計劃一樣，組織需要了解最佳名額才能控制其技術債務。

以下是一些值得關注的最佳名額：

(1)錯誤(Bug)

至少，軟體開發人員應該計算并跟蹤他們的錯誤。這包括已修複和未修複的錯誤。而關注未修複的錯誤可以讓開發團隊在靈活疊代期間專注于并修複它們。關注已修複的錯誤有助于團隊衡量他們的技術債務管理流程的有效性。

(2)代碼品質

雖然錯誤對軟體的最終使用者有更直接的影響，但代碼複雜性确實會損害開發團隊和整個組織。

尋找代碼複雜性名額，例如：

• 圈複雜度。
• 類耦合。
• 代碼行。
• 繼承深度。

這些名額越低越好。

密切關注這些名額還有助于組織準确地知道要返工或重構哪些代碼，以降低複雜性并改進軟體的後端。

(3)代碼内聚

與代碼品質一樣，專門關注代碼内聚性将有助于避免代碼變得過于複雜。高代碼内聚通常意味着代碼更易于維護、可重用和健壯。它還最大限度地減少了需要參與代碼開發的人數，這可以顯著降低複雜性，并減少位衰減的機會。

高内聚性是指有一個類執行定義良好的任務。

(4)代碼所有權

更多的開發工程師通常意味着更多的麻煩，而更多的麻煩通常會導緻更大的問題和更高水準的無意技術債務。這就是為什麼代碼所有權是一個如此有價值的名額：它回答了“誰專注于什麼代碼?”的問題。

該名額将使組織的項目管理人員關注處理各種代碼的人數。了解這些資訊将使這些團隊能夠減少用于這些工作的開發人員的人數和時間。但并不希望某個人擁有完整的代碼段，以防萬一離職或者出現意外。通常情況下，是讓開發工程師團隊擁有代碼庫中的域。

(5)Churn

代碼在被重寫/替換時被稱之為Churn。Churn是對給定代碼段看到的活動的度量。組織要關注到大量活動的代碼，因為其中的任何問題都會加劇。然後，度量流失可以幫助團隊識别代碼的哪些部分需要重構并确定其優先級。如果開發工程師必須不斷解決代碼同一部分的錯誤，那就意味着那裡出了問題。關注這種流失将幫助組織更快地查明這些問題，使他們能夠通過永久性解決方案來解決問題，進而降低技術債務。

跟蹤這些技術債務名額不會消除組織的所有債務，但會幫助更有效地管理。

什麼是技術債務統計?

一些研究機構已經進行了學術研究和調查，闡明了軟體行業對技術債務比喻的看法。

卡内基梅隆大學軟體工程研究所的一項行業調查發現，大多數參與者在這個比喻中發現了一些價值，盡管他們對具體定義略有不同。然而更有趣的是，他們關于技術債務成因的研究結果。

受訪者表示，第一，糟糕的架構選擇是他們技術債務的主要來源。第二是代碼過于複雜，第三是缺乏文檔和測試不充分。

這些結果表明，大多數受訪者表示無意中積累了技術債務。更糟糕的是，65%的參與者表示他們沒有管理技術債務的流程。這意味着他們因為缺乏戰略而積累了技術債務，并且選擇沒有解決這些問題的戰略。

一位擁有20多年與各種公司合作經驗的軟體開發人員建議，組織應該像還清信用卡一樣償還他們的技術債務。組織應該将投資重點集中在兩個地方：企業文化和代碼庫。

投資于企業文化似乎讓每個人都站在同一個立場上。這意味着要建立起讓人們共同負責的制度，意味着人們知道在做什麼。

而投資于代碼庫可能意味着執行更深入和更頻繁的品質保證測試。這些測試甚至可能是自動化的。這也可能意味着更頻繁的重構，特别是如果組織已經積累了大量技術債務的話。投資于代碼庫應該包括某種形式的代碼審查，以確定在問題變得失控之前得到解決。

在這些地方投資是很好的起點，但任何組織可以做的最有價值的事情就是管理他們的技術債務。如果沒有明确的戰略，技術債務将會繼續增長，并在未來帶來更多問題。

如何開始管理技術債務?

與金融債務一樣，隻有制定計劃加以管理，技術債務才會減少。但管理技術債務并非易事。它需要頻繁的監控和努力，并且已經成為軟體公司必不可少的一部分。技術債務很容易使組織偏離業務目标，是以管理它有助于與組織的其他部分保持一緻。

盡管如此，管理技術債務對于組織來說仍然感覺是一種負擔。項目經理、産品團隊和工程師已經不堪重負。這不是他們首先累積債務的原因嗎?而添加其他東西會增加他們的壓力水準嗎?也許是這樣，但想要将技術債務保持在較低水準的組織必須将其作為優先事項。這隻是一個很大的需求，尤其是當檢視統計資料時。

根據調研機構的預測，到2024年，尚未解決的技術債務将使全球各地的公司損失4萬億美元，而那些償還技術債務的企業向客戶的交貨時間将縮短50%。

在過去的幾年中，新技術應用程式已經讓軟體公司認識到這種需求，并尋求方法來滿足它。

現在，有了Stepsize之類的軟體，開發團隊可以輕松地報告債務、對債務報告進行分類，并确定需要解決的最重要的債務部分，進而幫助組織管理其技術債務。所有這些都有助于軟體工程團隊管理他們的技術債務，而不會徹底改變他們的正常工作流程。更重要的是，它使他們能夠快速開發出優秀的軟體，同時監控他們積累的技術債務。