【51CTO.com快譯】通常而言，債務(wù)是一個能夠讓人產(chǎn)生消極感覺的詞匯。大家往往會聯(lián)想到學(xué)生貸、醫(yī)療費、以及抵押付款等景象。不過，一些金融上的債務(wù)還是多少對人有益的。而技術(shù)債也是如此。

[[352954]]

作為一個隱喻，技術(shù)債(也稱為代碼債務(wù))是指開發(fā)團隊為了加快項目或功能的交付速度，在后期需要重構(gòu)時會發(fā)生的情況。顯然，優(yōu)先事項是更快的開發(fā)過程，而不是更高質(zhì)量的代碼。

和金融債務(wù)類似，技術(shù)債對于組織來說是一把雙刃劍。為了合理地使用它，工程師和團隊負(fù)責(zé)人必須監(jiān)控他們手頭有多少技術(shù)債，并學(xué)習(xí)如何對其進(jìn)行良好的管理。而對于組織而言，這將是一項艱巨的任務(wù)，尤其是當(dāng)他們對技術(shù)債的優(yōu)缺點尚不清楚時。

技術(shù)債的基本特征

Scrum已經(jīng)成為了軟件開發(fā)人員在尋求以更高效的方式交付產(chǎn)品時，使用到的流行框架。眾所周知，客戶經(jīng)常會有新的需求出現(xiàn)，并且會改變主意。因此，開放性的Scrum以事情的不可預(yù)測性為重要原則，并讓用戶在使用該框架時產(chǎn)生技術(shù)債。

在此，我們借用Scrum培訓(xùn)師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)曾經(jīng)提到過的，如下兩種不同類型的Scrum技術(shù)債：

• 首先創(chuàng)建一個由性能欠佳的代碼所組成的短期解決方案，以便開發(fā)團隊可以更快地交付產(chǎn)品。同時，團隊期望在初次發(fā)布之后，回過頭來改善代碼的質(zhì)量。
• 隨著開發(fā)團隊發(fā)現(xiàn)有關(guān)待解決問題信息的增多，另一類技術(shù)債也會被動地產(chǎn)生。即：隨著新需求的出現(xiàn)，往日起作用的解決方案可能在將來就失效了。因此，這些需要調(diào)整和重構(gòu)的代碼，會包含一定數(shù)量的債務(wù)。

Wolper同時認(rèn)為：Scrum團隊?wèi)?yīng)該重視如下方面：

• 為了簡便管理，應(yīng)優(yōu)先考慮技術(shù)債的透明度。團隊需要將技術(shù)債的可視化突顯效果放在首位，并在每次Sprint(沖刺)會議期間審查技術(shù)債的各項需求。
• 跟蹤技術(shù)債。團隊通過盡可能地使用諸如圈復(fù)雜度(cyclomatic complexity)、代碼覆蓋率、SQALE評級、以及違反規(guī)則等深入的代碼度量標(biāo)準(zhǔn)，對各類錯誤進(jìn)行記錄和計數(shù)。
• 快速定期償還債務(wù)。Scrum團隊?wèi)?yīng)該考慮在每個Sprint周期中，將其15-20%的資源分配給重構(gòu)代碼并修復(fù)錯誤。
• 調(diào)整產(chǎn)品的積壓，將其與償還的技術(shù)債任務(wù)關(guān)聯(lián)。您可以將債務(wù)整理成要解決的Sprint狀態(tài)，以有助于防止債務(wù)被遺忘。
• 調(diào)整對“完成”的定義，即：在滿足了那些可管理的技術(shù)債的既定標(biāo)準(zhǔn)之前，請不要將其狀態(tài)設(shè)置為完成。
• 規(guī)范程序。為團隊如何處理添加新的功能(包括引入技術(shù)債)，制定可重復(fù)的公式。

技術(shù)債有哪些不同類型?

目前，大多數(shù)專家普遍認(rèn)為技術(shù)債有故意和無意的兩種類型。其中：

• 當(dāng)組織為了縮短上市時間而選擇留出改進(jìn)代碼的空間時，就會產(chǎn)生故意的(也稱為主動)技術(shù)債。
• 當(dāng)在發(fā)布了一段時間create后需要提高代碼的質(zhì)量時，就會產(chǎn)生無意的(也稱為偶然的、過時的、被動的)技術(shù)債。這些既可能是由于第一次發(fā)布不佳所致，也可能是由于代碼過時而自然產(chǎn)生的更新需求。

另一種觀點則根據(jù)技術(shù)的具體類別，以及組織預(yù)期的更好服務(wù)，提出了如下13種不同類型的技術(shù)債，每一種債務(wù)都包含了標(biāo)題中的特定問題：

• 建筑債務(wù)
• 構(gòu)建債務(wù)
• 代碼債務(wù)
• 缺陷債務(wù)
• 設(shè)計債務(wù)
• 文件債務(wù)
• 基礎(chǔ)設(shè)施債務(wù)
• 人員債務(wù)
• 處理債務(wù)
• 需求債務(wù)
• 服務(wù)債務(wù)
• 測試自動化債務(wù)
• 測試債務(wù)

Martin Fowler在故意和無意的分類基礎(chǔ)上增加了魯莽和謹(jǐn)慎兩個維度，提出了技術(shù)債的四象限。其中謹(jǐn)慎的技術(shù)債來自一個知道如何做的團隊，而當(dāng)人們太草率時，魯莽的債務(wù)就會產(chǎn)生。兩者的區(qū)別在于：審慎的團隊是在了解其行為的基礎(chǔ)上，故意地去使用技術(shù)債。而魯莽的團隊則像是剛剛經(jīng)歷了雙十一剁手節(jié)一樣，碰到債務(wù)的不斷增加。

可見，對于所有的軟件工程團隊而言，無論他們的專業(yè)知識或經(jīng)驗如何，適當(dāng)承擔(dān)一定程度的債務(wù)是可以接受的。也就是說，在謹(jǐn)慎的情況下，一些可以預(yù)期的債務(wù)會促進(jìn)團隊知曉應(yīng)當(dāng)對手頭的項目做些什么，以及哪些是稍后要進(jìn)行的一些新工作。他們不但會盡力減少魯莽的債務(wù)，還能減少不良代碼，以提高軟件的質(zhì)量。

應(yīng)當(dāng)始終避免哪種類型的技術(shù)債?

審慎的技術(shù)債雖然對軟件組織來說有一定的好處，但是如果累積得多了，從量變發(fā)生了質(zhì)變，也可能會成為魯莽的技術(shù)債。也就是說，當(dāng)軟件隨著時間的流逝，惡化到產(chǎn)生錯誤、甚至影響其功能和可用性時，就會成為Bit rot(也稱為“軟件熵”)。例如：當(dāng)開發(fā)人員需要對其不甚了解的歷史遺留代碼進(jìn)行較小的增量更改時，軟件本身的復(fù)雜性和潛在問題會隨即增加。一些工程師甚至可能違反NFR(Non-functional requirement，非功能要求)，完全破壞代碼，進(jìn)而對軟件的整體功能產(chǎn)生影響。解決此類技術(shù)債的唯一方法便是重構(gòu)整個過程。

而且，在大多數(shù)情況下，團隊并不會察覺到自己的一些微小變化，實際上會導(dǎo)致債務(wù)總額的增加。雖然我們也可以使用Wolper的透明化概念，協(xié)助避免此類災(zāi)難的發(fā)生，但是從根本上說，團隊還是應(yīng)當(dāng)對目標(biāo)軟件具有充分的了解，從而避免在無意中添加可能阻礙系統(tǒng)的代碼。

技術(shù)債的指標(biāo)有哪些?

和任何良好的管理計劃類似，組織需要通過了解各項指標(biāo)，才能獲得對于技術(shù)債的控制權(quán)。下面是一些值得參考與衡量的指標(biāo)：

軟件缺陷

軟件開發(fā)者應(yīng)當(dāng)持續(xù)記錄和跟蹤發(fā)現(xiàn)到的缺陷，其中包括未修復(fù)的缺陷和已修復(fù)的缺陷。對于未修復(fù)的缺陷，開發(fā)團隊可以在敏捷迭代中持續(xù)專注和修復(fù)它們。而通過跟蹤已修復(fù)的缺陷，團隊則能夠衡量其技術(shù)債的管理流程與效率。

代碼質(zhì)量

如果說軟件缺陷直接影響的是軟件的最終用戶，那么代碼的復(fù)雜性則會阻礙團隊的開發(fā)與維護。下面是有關(guān)代碼復(fù)雜度的指標(biāo)：

• 圈復(fù)雜度
• 類的耦合
• 代碼行數(shù)
• 繼承的深度

當(dāng)然，這些指標(biāo)應(yīng)該越低越好。通過密切關(guān)注這些指標(biāo)，團隊還能夠準(zhǔn)確地獲悉有待重寫或重構(gòu)的代碼，以降低復(fù)雜性，并改善軟件的后端。

代碼的內(nèi)聚

與代碼質(zhì)量類似，專注代碼的內(nèi)聚性，將有助于簡化代碼的復(fù)雜性。較高的代碼內(nèi)聚性通常意味著目標(biāo)代碼更具有可維護性、可重用性和魯棒性。同時，該指標(biāo)還可以最大程度地減少需要開發(fā)人員的數(shù)量，以及大幅降低復(fù)雜性，減少Bit rot。

代碼所有權(quán)

“人多手雜”在此可以被用來形容更多的開發(fā)人員，產(chǎn)生更多的工作量，導(dǎo)致更大的問題，以及更多的無意技術(shù)債。因此，我們需要祭出“代碼所有權(quán)”的指標(biāo)，來解答“誰在關(guān)注哪塊代碼?”，以及“如果出現(xiàn)問題該找誰?”等問題。

此類指標(biāo)將向項目管理人員展示從事某項代碼工作的人員數(shù)量，以及花費在控制上的時間。據(jù)此，我們可以避免由于完整的代碼部分被掌握在某個成員手里，而他可能因為被堵在路上，而耽誤了項目進(jìn)度等單點故障。因此，我們可以將代碼庫分割成不同的域，然后授權(quán)給團隊中不同的開發(fā)人員角色。

代碼變化(Churn)

代碼段被重寫或替換等活動都可以被視為發(fā)生了代碼變化。如果開發(fā)人員不得不圍繞著某段代碼持續(xù)解決相似的錯誤，那么就意味著此處的技術(shù)債非常嚴(yán)重。據(jù)此，團隊也可以識別并確定代碼的哪些部分需要重構(gòu)。因此，團隊需要特別注意那些經(jīng)常發(fā)生變化的代碼，以便快速發(fā)現(xiàn)問題，進(jìn)而避免問題的加劇和技術(shù)債的累積。

值得一提的是，簡單地跟蹤上述技術(shù)債的各項指標(biāo)，并不能自動消除所有的債務(wù)，我們?nèi)匀恍枰鼮橛行У墓芾韺嵺`。

有關(guān)技術(shù)債的調(diào)查

根據(jù)卡內(nèi)基梅隆大學(xué)軟件工程學(xué)院的一項行業(yè)調(diào)查(請參見--https://insights.sei.cmu.edu/sei_blog/2015/07/a-field-study-of-technical-debt.html)發(fā)現(xiàn)：糟糕的架構(gòu)往往是技術(shù)債的首要來源，其次是過于復(fù)雜的代碼，第三則是缺少文檔和測試之間的緊密聯(lián)系。而更糟糕的是，有65%的受訪者表示他們沒有適當(dāng)?shù)募夹g(shù)債管理應(yīng)用。這就意味著由于缺乏策略來應(yīng)對技術(shù)債，因此他們選擇不去實施任何解決方案!

一位擁有與多家公司(從《財富》500強到初創(chuàng)公司)合作超過20年經(jīng)驗的軟件開發(fā)人員建議：開發(fā)團隊?wèi)?yīng)當(dāng)像投資信用卡業(yè)務(wù)那樣去投資技術(shù)債，而且投資的重點應(yīng)放在如下兩個地方：

• 公司的文化，將人員對應(yīng)到復(fù)雜的系統(tǒng)上，各司其職。
• 代碼庫的構(gòu)建，執(zhí)行更深入和更頻繁的質(zhì)量保障測試。在組織已經(jīng)積累了大量技術(shù)債的情況下，您可以將此類測試自動化。投資的內(nèi)容至少涉及到通過某種形式的代碼審查，以確保問題能夠被盡早地解決。當(dāng)然，這也意味著需要更加頻繁地進(jìn)行重構(gòu)。

不過，上述兩方面的投資只是一個起點，我們?nèi)匀粡娬{(diào)需要管理自己的技術(shù)債。如果沒有一個明確的策略，技術(shù)債會繼續(xù)增加，并在線上和線下制造更多的問題，正如上述調(diào)查中所提到的那樣。

如何管理技術(shù)債?

就像金融債務(wù)一樣，只有通過制定計劃，實施管理，才能減少技術(shù)債。當(dāng)然，正所謂“知易行難”，我們真正管理起來并不容易。它需要持續(xù)的監(jiān)控和投入，并將其納入軟件開發(fā)的必要組成部分。而且，由于技術(shù)債很容易脫離業(yè)務(wù)目標(biāo)，因此對其管理有助于讓開發(fā)與業(yè)務(wù)目標(biāo)保持一致。

據(jù)預(yù)測，到2024年，技術(shù)債務(wù)將給全球科技公司帶來4萬億美元的損失。而實施了技術(shù)債管理與補救的公司將會縮短50%客戶產(chǎn)品交付時間。

目前，市場上已有一些新的技術(shù)應(yīng)用捕捉到了此類軟件需求，并提出了相應(yīng)的解決方案。例如，Stepsize之類的軟件，便可以使開發(fā)團隊輕松地獲取債務(wù)報告，對它們進(jìn)行分類，并確定有待解決的最重要債務(wù)。通過監(jiān)控并管理積累的所有技術(shù)債，它們可以協(xié)助軟件工程團隊在無需大幅改變常規(guī)工作流程的前提下，及時交付出色的軟件產(chǎn)品。

原文標(biāo)題：The Engineer’s Complete Guide to Technical Debt，作者：Alex Omeyer

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