[[412100]]

【51CTO.com快譯】債務是一個復雜的話題。而軟件開發(fā)工程師需要了解什么是技術債務以及如何有效管理技術債務以加速軟件開發(fā)過程。

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

技術債務也是如此。技術債務(也稱之為代碼債務)是指開發(fā)團隊加快交付今后可能需要重構(gòu)的項目或功能時會發(fā)生的情況。對于開發(fā)團隊來說，加快開發(fā)過程成為優(yōu)先事項，而不是高質(zhì)量的代碼。

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

技術債務是一個隱喻性框架，可以用于思考在開發(fā)團隊加快軟件生產(chǎn)之后需要重構(gòu)的細節(jié)。

技術債務有哪些同義詞?

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

• 技術債務(Tech debt)：技術債務的簡寫或昵稱。
• 設計債務：與軟件的設計元素有關的技術債務。
• 代碼債務：與程序員必須重構(gòu)的軟件系統(tǒng)中的不良代碼相關的技術債務。

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

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

Scrum如今已經(jīng)成為軟件開發(fā)人員在尋求以更有效的方式交付產(chǎn)品時使用的流行框架。Scrum的一個關鍵原則是事情是不可預測的：客戶改變主意或經(jīng)常出現(xiàn)新需求。這種對變化的開放，意味著組織在使用Scrum框架時可能會出現(xiàn)技術債務。

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

• 首先是主動選擇創(chuàng)建由不完美代碼組成的短期解決方案，以便可以更快地交付產(chǎn)品。期望開發(fā)團隊會在初始發(fā)布之后并不斷來改進代碼質(zhì)量。
• 當開發(fā)團隊發(fā)現(xiàn)有關他們試圖解決的問題的更多信息時，另一種類型的技術債務可能會出現(xiàn)。隨著新需求的出現(xiàn)，以往有效的解決方案如今可能無法奏效。其代碼需要調(diào)整和重構(gòu)，這樣就產(chǎn)生了一些技術債務。

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

他說，Scrum團隊應該：

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

(2)跟蹤技術債務。Wolpers建議對錯誤進行計數(shù)，并盡可能使用更深入的代碼指標，如圈復雜度、代碼覆蓋率、SQALE評級以及規(guī)則。

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

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

(5)調(diào)整對“完成”的定義。在達到可管理的技術債務的既定標準之前，不要將某事視為已經(jīng)完成。

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

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

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

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

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

當代碼質(zhì)量在一段時間后需要改進時，就會發(fā)生無意的技術債務(也稱為偶然的、過時的、被動的或無意的)。這可能是第一次生產(chǎn)不佳的結(jié)果，或者只是隨著代碼過時而自然需要更新。

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

• 架構(gòu)債務
• 積累債務
• 代碼債務
• 缺陷債務
• 設計債務
• 文件債務
• 基礎設施債務
• 人員債務
• 處理債務
• 要求債務
• 服務債務
• 測試自動化債務
• 測試債務

雖然這些債務分類方法還有其他細節(jié)，但最流行的債務分類方法來自Martin Fowler的技術債務象限。與Ward Cunningham一樣，Martin Fowler是敏捷軟件開發(fā)宣言的17位作者之一。然而當談到技術債務時，F(xiàn)owler獨自開發(fā)了他所謂的“技術債務象限”。

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

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

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

這個象限產(chǎn)生四種不同類型的技術債務：

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

有意債務發(fā)生在創(chuàng)造的選擇中，無意債務發(fā)生在團隊需要做出調(diào)整之后。然而，謹慎債務和魯莽債務的區(qū)別更加獨特，這種分類賦予了技術債務象限的價值。謹慎的技術債務來自一個知道自己在做什么的團隊，而當他們做事過于草率時，就會產(chǎn)生魯莽的債務。

能看出謹慎和魯莽的區(qū)別嗎?

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

魯莽的團隊只是將他們的軟件系統(tǒng)視為瘋狂購物的美國運通銀行持卡人，將導致技術債務不斷地積累。

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

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

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

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

位衰減(也稱為“數(shù)據(jù)腐化”)發(fā)生在軟件隨著時間的推移而退化到產(chǎn)生錯誤甚至改變其功能和可用性的程度時。位衰減需要一些時間來開發(fā)，但它將讓開發(fā)團隊更加謹慎。

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

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

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

什么是技術債務指標?

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

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

以下是一些值得關注的最佳指標：

(1)錯誤(Bug)

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

(2)代碼質(zhì)量

雖然錯誤對軟件的最終用戶有更直接的影響，但代碼復雜性確實會損害開發(fā)團隊和整個組織。

尋找代碼復雜性指標，例如：

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

這些指標越低越好。

密切關注這些指標還有助于組織準確地知道要返工或重構(gòu)哪些代碼，以降低復雜性并改進軟件的后端。

(3)代碼內(nèi)聚

與代碼質(zhì)量一樣，專門關注代碼內(nèi)聚性將有助于避免代碼變得過于復雜。高代碼內(nèi)聚通常意味著代碼更易于維護、可重用和健壯。它還最大限度地減少了需要參與代碼開發(fā)的人數(shù)，這可以顯著降低復雜性，并減少位衰減的機會。

高內(nèi)聚性是指有一個類執(zhí)行定義良好的任務。

(4)代碼所有權

更多的開發(fā)工程師通常意味著更多的麻煩，而更多的麻煩通常會導致更大的問題和更高水平的無意技術債務。這就是為什么代碼所有權是一個如此有價值的指標：它回答了“誰專注于什么代碼?”的問題。

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

(5)Churn

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

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

什么是技術債務統(tǒng)計?

一些研究機構(gòu)已經(jīng)進行了學術研究和調(diào)查，闡明了軟件行業(yè)對技術債務比喻的看法。

卡內(nèi)基梅隆大學軟件工程研究所的一項行業(yè)調(diào)查發(fā)現(xiàn)，大多數(shù)參與者在這個比喻中發(fā)現(xiàn)了一些價值，盡管他們對具體定義略有不同。然而更有趣的是，他們關于技術債務成因的研究結(jié)果。

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

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

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

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

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

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

如何開始管理技術債務?

與金融債務一樣，只有制定計劃加以管理，技術債務才會減少。但管理技術債務并非易事。它需要頻繁的監(jiān)控和努力，并且已經(jīng)成為軟件公司必不可少的一部分。技術債務很容易使組織偏離業(yè)務目標，因此管理它有助于與組織的其他部分保持一致。

盡管如此，管理技術債務對于組織來說仍然感覺是一種負擔。項目經(jīng)理、產(chǎn)品團隊和工程師已經(jīng)不堪重負。這不是他們首先累積債務的原因嗎?而添加其他東西會增加他們的壓力水平嗎?也許是這樣，但想要將技術債務保持在較低水平的組織必須將其作為優(yōu)先事項。這只是一個很大的需求，尤其是當查看統(tǒng)計數(shù)據(jù)時。

根據(jù)調(diào)研機構(gòu)的預測，到2024年，尚未解決的技術債務將使全球各地的公司損失4萬億美元，而那些償還技術債務的企業(yè)向客戶的交貨時間將縮短50%。

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

現(xiàn)在，有了Stepsize之類的軟件，開發(fā)團隊可以輕松地報告?zhèn)鶆?、對債務報告進行分類，并確定需要解決的最重要的債務部分，從而幫助組織管理其技術債務。所有這些都有助于軟件工程團隊管理他們的技術債務，而不會徹底改變他們的常規(guī)工作流程。更重要的是，它使他們能夠快速開發(fā)出優(yōu)秀的軟件，同時監(jiān)控他們積累的技術債務。

原文作者：The Engineer’s Complete Guide to Technical Debt，作者：Alex Omeyer

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】