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

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

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

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

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

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

技術債務有哪些同義詞?

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

• 技術債務(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之類的軟體，開發團隊可以輕鬆地報告債務、對債務報告進行分類，並確定需要解決的最重要的債務部分，從而幫助組織管理其技術債務。所有這些都有助於軟體工程團隊管理他們的技術債務，而不會徹底改變他們的常規工作流程。更重要的是，它使他們能夠快速開發出優秀的軟體，同時監控他們積累的技術債務。