點(diǎn)擊下方“JavaEdge”，選擇“設(shè)為星標(biāo)”

第一時(shí)間關(guān)注技術(shù)干貨！

免責(zé)聲明~ 任何文章不要過(guò)度深思！ 萬(wàn)事萬(wàn)物都經(jīng)不起審視，因?yàn)槭郎蠜](méi)有同樣的成長(zhǎng)環(huán)境，也沒(méi)有同樣的認(rèn)知水平，更「沒(méi)有適用于所有人的解決方案」； 不要急著評(píng)判文章列出的觀點(diǎn)，只需代入其中，適度審視一番自己即可，能「跳脫出來(lái)從外人的角度看看現(xiàn)在的自己處在什么樣的階段」才不為俗人。 怎么想、怎么做，全在乎自己「不斷實(shí)踐中尋找適合自己的大道」

0 前言

軟件開(kāi)發(fā)的核心在于應(yīng)對(duì)變化。在軟件的生命周期中，目標(biāo)是能夠在合理的時(shí)間內(nèi)實(shí)施必要的更改。不管這些更改是技術(shù)性的，比如緊急安全升級(jí)，還是業(yè)務(wù)需求所驅(qū)動(dòng)的，比如開(kāi)發(fā)新功能以在目標(biāo)市場(chǎng)中更具競(jìng)爭(zhēng)力——能否快速應(yīng)對(duì)變化是成敗的關(guān)鍵。

是什么讓我們慢下來(lái)？通常，這是因?yàn)樽屇硞€(gè)功能能夠運(yùn)行并不等于讓它在長(zhǎng)期內(nèi)具備良好的可維護(hù)性（參考 Google 軟件工程實(shí)踐）。第一個(gè)可運(yùn)行版本通常是快速而粗糙的，而讓其具備可修改性則需要額外的努力。這引出了“技術(shù)債務(wù)”的隱喻（參考 Ward 的解釋）。開(kāi)發(fā)人員選擇暫時(shí)不投資于代碼的可變更性，而是承受技術(shù)債務(wù)，以便更快完成任務(wù)。之后，每次修改代碼都需要支付額外的“利息”，直到技術(shù)債務(wù)徹底清償。

1 啥是技術(shù)債？

技術(shù)債務(wù)是指當(dāng)前軟件狀態(tài)與最適合于輕松實(shí)現(xiàn)更改的目標(biāo)狀態(tài)之間的差距。在某些情況下，積累技術(shù)債務(wù)可能是值得的——例如，為了滿足一個(gè)硬性截止日期，否則整個(gè)項(xiàng)目可能停滯不前。但從長(zhǎng)遠(yuǎn)來(lái)看，采取措施來(lái)控制和減少技術(shù)債務(wù)無(wú)疑是明智的（參考 Fowler 的文章）。

對(duì)于壽命預(yù)計(jì)以年為單位的軟件來(lái)說(shuō)，是否償還技術(shù)債務(wù)并不是問(wèn)題。問(wèn)題在于如何識(shí)別、衡量和管理它。

技術(shù)債務(wù)可能有不同的來(lái)源。例如，團(tuán)隊(duì)可能對(duì)技術(shù)債務(wù)引發(fā)的問(wèn)題缺乏認(rèn)識(shí)；或者，盡管意識(shí)到問(wèn)題存在，但誤以為永遠(yuǎn)沒(méi)有時(shí)間解決。這與工程文化密切相關(guān)。隨著時(shí)間推移，問(wèn)題只會(huì)越來(lái)越嚴(yán)重（參考 破窗理論）。另一種情況是，團(tuán)隊(duì)在權(quán)衡利弊后，有意積累技術(shù)債務(wù)。第三種情況則是因?yàn)槲覀儫o(wú)法事先掌握所有信息，需求可能變化，而開(kāi)發(fā)過(guò)程中會(huì)逐步學(xué)習(xí)。這種債務(wù)即使對(duì)于最優(yōu)秀的團(tuán)隊(duì)來(lái)說(shuō)也不可避免（參考 Fowler 的技術(shù)債務(wù)象限）。

技術(shù)債務(wù)的棘手之處在于，它通過(guò)不斷做出小的妥協(xié)而逐漸積累。為了短期的便利和簡(jiǎn)單而犧牲長(zhǎng)期的結(jié)果，被稱為“溫水煮青蛙隱喻”。換句話說(shuō)，問(wèn)題會(huì)逐漸積累，直到災(zāi)難發(fā)生為止。我們?nèi)绾畏乐惯@種情況的發(fā)生？

應(yīng)對(duì)技術(shù)債務(wù)的最佳防御措施是從一開(kāi)始就使其可見(jiàn)。然后，我們可以通過(guò)設(shè)立適當(dāng)?shù)慕】抵笜?biāo)，并盡早采取糾正措施來(lái)主動(dòng)管理它。

另一方面，如果我們的系統(tǒng)已經(jīng)因?yàn)榧夹g(shù)債務(wù)瀕臨崩潰，那就需要采取更激進(jìn)的“清理”措施——在為時(shí)已晚之前。在這種情況下，建議建立多個(gè)改進(jìn)指標(biāo)，并使用它們來(lái)跟蹤這些措施的進(jìn)展。

2 WTFs 每分鐘

一個(gè)廣泛認(rèn)可的觀點(diǎn)是，代碼質(zhì)量的唯一有效衡量指標(biāo)是每分鐘 WTF 次數(shù)（參考 Martin 的《代碼整潔之道》）?；蛟S可以開(kāi)發(fā)一款設(shè)備，專門用來(lái)統(tǒng)計(jì) WTF 次數(shù)，這或許會(huì)成為一個(gè)不錯(cuò)的創(chuàng)業(yè)點(diǎn)子？

當(dāng)然，這個(gè)指標(biāo)既主觀又依賴于開(kāi)發(fā)者的技術(shù)水平及團(tuán)隊(duì)的工程文化。根據(jù)破窗理論，糟糕的代碼越多，就越會(huì)鼓勵(lì)開(kāi)發(fā)人員繼續(xù)制造技術(shù)債務(wù)。

3 代碼異味的數(shù)量

Martin Fowler 和 Kent Beck 引入了“代碼異味”這一概念，幫助開(kāi)發(fā)者識(shí)別代碼中可能存在問(wèn)題的地方。Fowler 的《重構(gòu)》一書(shū)列舉了 24 個(gè)代碼異味示例。Uncle Bob 的《代碼整潔之道》中也包含了許多代碼異味和啟發(fā)式規(guī)則（參考《[代碼整潔之道》第17章]。一些代碼異味，如重復(fù)代碼和過(guò)長(zhǎng)函數(shù)，可以通過(guò)靜態(tài)分析工具（如 [SonarQube]輕松檢測(cè)。然而，許多代碼異味無(wú)法通過(guò)靜態(tài)工具輕松發(fā)現(xiàn)。這也是為什么需要像“每分鐘 WTF 次數(shù)”這樣的另一個(gè)指標(biāo)。

4 自動(dòng)化測(cè)試覆蓋率

盡管早在《Google 軟件工程實(shí)踐》等書(shū)中提到過(guò)自動(dòng)化測(cè)試的重要性，最近的研究（例如《Accelerate》和 DORA 研究）表明，測(cè)試自動(dòng)化與軟件生產(chǎn)力之間存在統(tǒng)計(jì)上的正相關(guān)。這表明，提高自動(dòng)化測(cè)試覆蓋率通?？梢燥@著提升團(tuán)隊(duì)的生產(chǎn)力。

可以通過(guò)許多工具（例如 [JaCoCo]來(lái)追蹤這個(gè)指標(biāo)。但如同許多其他指標(biāo)一樣，它也容易被“造假”，比如編寫大量實(shí)際上并未測(cè)試任何內(nèi)容的測(cè)試。因此，結(jié)合其他努力來(lái)提升團(tuán)隊(duì)技能，并闡明編寫自測(cè)試代碼的好處是非常重要的——比如 Google 推行的廁所上的測(cè)試。

當(dāng)測(cè)試自動(dòng)化覆蓋率較低成為限制團(tuán)隊(duì)進(jìn)步的因素時(shí)，這一指標(biāo)尤為有效。例如，我的團(tuán)隊(duì)曾發(fā)現(xiàn)某個(gè)遺留組件的測(cè)試自動(dòng)化覆蓋率非常低（僅約50%）。因此，我們將提高該覆蓋率作為優(yōu)先事項(xiàng)。通過(guò)持續(xù)監(jiān)控指標(biāo)、在團(tuán)隊(duì)回顧會(huì)議上討論進(jìn)展，我們?cè)谝荒陜?nèi)將單元測(cè)試覆蓋率提升至80%，并且不再視其為限制因素?，F(xiàn)在，我們將其作為代碼庫(kù)健康的一個(gè)重要指標(biāo)。

5 文檔覆蓋率

文檔不足可能對(duì)團(tuán)隊(duì)效率產(chǎn)生負(fù)面影響。因此，我們可以采用一個(gè)與文檔覆蓋率相關(guān)的指標(biāo)：

文檔覆蓋率：系統(tǒng)中文檔覆蓋部分占總系統(tǒng)的百分比。

如何使用這個(gè)指標(biāo)？在文檔不足被視為制約因素的團(tuán)隊(duì)中，可以優(yōu)先改善這一問(wèn)題。我們列出所有組件，并評(píng)估每個(gè)組件當(dāng)前的文檔覆蓋情況。每周更新指標(biāo)，并監(jiān)控改進(jìn)進(jìn)展。

6 用在棄用組件上的精力

在一些情況下，為了支持新的組件，我們需要棄用舊組件，但在一段時(shí)間內(nèi)仍然不得不保留這些組件。例如，有些客戶端需要時(shí)間完成遷移。在此期間，我們?nèi)钥赡苄枰獙?duì)這些棄用組件進(jìn)行工作，比如修復(fù)漏洞。由于這些棄用組件最終會(huì)被移除，這種工作實(shí)際上是一種浪費(fèi)。問(wèn)題是，團(tuán)隊(duì)往往會(huì)“忘記”這些棄用組件，繼續(xù)對(duì)它們提供支持。隨著時(shí)間推移，這些工作會(huì)不斷積累，甚至可能成為團(tuán)隊(duì)的主要限制因素之一。因此，跟蹤棄用組件并盡早廢止它們是非常重要的。

可以采用以下指標(biāo)：

• 棄用組件工作的比例= 用在棄用組件上的時(shí)間 / 總時(shí)間

• 棄用組件工作的比例= 與棄用組件相關(guān)的任務(wù)數(shù) / 總?cè)蝿?wù)數(shù)

• 棄用變更比例= 棄用組件的變更數(shù) / 總變更數(shù)

如何使用這些指標(biāo)？例如，我的團(tuán)隊(duì)負(fù)責(zé)一個(gè)覆蓋 200 多個(gè)國(guó)家的住宿合作伙伴門戶中與發(fā)票相關(guān)的財(cái)務(wù)內(nèi)容。去年，我們開(kāi)發(fā)了一個(gè)新的發(fā)票展示頁(yè)面，并在幾乎所有國(guó)家推出。然而，由于一些國(guó)家有特定邏輯，我們決定暫時(shí)保留舊頁(yè)面以便后續(xù)遷移。這一決定讓我們可以更快地獲得新頁(yè)面的反饋。然而，這也導(dǎo)致我們?cè)趲讉€(gè)月內(nèi)需要支持多個(gè)版本的頁(yè)面。盡管舊頁(yè)面的支持工作量不大，但累積效應(yīng)可能會(huì)顯著增加負(fù)擔(dān)。在這種情況下，我們將這一指標(biāo)作為改進(jìn)和健康監(jiān)控的重要工具。

7 用于修復(fù)用戶發(fā)現(xiàn)缺陷的工作量

軟件中的缺陷顯然會(huì)減緩功能開(kāi)發(fā)的進(jìn)度。因此，這些缺陷可以被視為技術(shù)債務(wù)的一部分。

我們可以使用以下指標(biāo)來(lái)量化相關(guān)工作量：

• %修復(fù)缺陷的工作量= 修復(fù)缺陷所花的時(shí)間 / 總時(shí)間

• %修復(fù)缺陷的工作量= 缺陷數(shù)量 / 總?cè)蝿?wù)數(shù)量

在 OWASP Top Ten 網(wǎng)絡(luò)應(yīng)用安全風(fēng)險(xiǎn)列表中，“漏洞和過(guò)時(shí)組件”被列為其中之一。這些問(wèn)題可能導(dǎo)致緊急計(jì)劃外工作，來(lái)修復(fù)漏洞和應(yīng)對(duì)后果。因此，漏洞可以被視為技術(shù)債務(wù)的一部分。

我們可以使用工具 Dependency-Check 來(lái)檢查項(xiàng)目中的依賴項(xiàng)。將該工具集成到 CI/CD 流水線中是廣泛認(rèn)可的最佳實(shí)踐。這種方法可以幫助我們盡早發(fā)現(xiàn)并修復(fù)漏洞或過(guò)時(shí)組件，從而減少技術(shù)債務(wù)帶來(lái)的潛在影響。

9 清償技術(shù)債務(wù)所需的估計(jì)工作量

有些導(dǎo)致團(tuán)隊(duì)效率降低的問(wèn)題無(wú)法通過(guò)靜態(tài)分析工具輕松追蹤。例如，共享數(shù)據(jù)庫(kù)架構(gòu)或其他復(fù)雜的架構(gòu)問(wèn)題，通常難以用工具直接衡量。每個(gè)團(tuán)隊(duì)都會(huì)面臨其獨(dú)特的技術(shù)債務(wù)挑戰(zhàn)，因此解決方法也會(huì)有所不同。

最簡(jiǎn)單的衡量方式可能是估算清償技術(shù)債務(wù)所需的工作量。然而，這種估算需要團(tuán)隊(duì)具備足夠的技能和經(jīng)驗(yàn)，例如掌握設(shè)計(jì)模式、重構(gòu)技巧、自測(cè)試代碼的編寫，甚至是架構(gòu)最佳實(shí)踐（如松耦合架構(gòu)）等。通過(guò)結(jié)合這些能力，我們可以更準(zhǔn)確地評(píng)估并應(yīng)對(duì)技術(shù)債務(wù)。

10 關(guān)鍵總結(jié)

• 技術(shù)債務(wù)是指當(dāng)前軟件狀態(tài)與最適合輕松實(shí)現(xiàn)更改的目標(biāo)狀態(tài)之間的差距。

• 在幾乎所有情況下，保持技術(shù)債務(wù)處于較低水平是非常重要的。如果忽視它，每次修改代碼時(shí)都會(huì)付出額外的努力。

• 技術(shù)債務(wù)的來(lái)源包括：(i) 團(tuán)隊(duì)對(duì)其危害缺乏認(rèn)識(shí)；(ii) 在權(quán)衡利弊后有意選擇積累技術(shù)債務(wù)；(iii) 由于信息不完整，隨著開(kāi)發(fā)過(guò)程中的學(xué)習(xí)和需求變化不可避免地產(chǎn)生的債務(wù)。

• 技術(shù)債務(wù)往往通過(guò)無(wú)數(shù)次小的妥協(xié)逐漸積累，最終可能導(dǎo)致嚴(yán)重后果。

• 最好的實(shí)踐是從一開(kāi)始就讓技術(shù)債務(wù)變得可見(jiàn)，并通過(guò)設(shè)置健康指標(biāo)進(jìn)行監(jiān)控，在早期采取糾正措施。

• 如果發(fā)現(xiàn)技術(shù)債務(wù)已經(jīng)威脅到系統(tǒng)的正常運(yùn)行，則需要采取更加激進(jìn)的清理措施。在這種情況下，可以通過(guò)設(shè)立改進(jìn)指標(biāo)并定期跟蹤進(jìn)展來(lái)評(píng)估和調(diào)整清理策略。

• 各團(tuán)隊(duì)可以使用多種指標(biāo)來(lái)衡量技術(shù)債務(wù)的健康狀況和改進(jìn)效果，例如 WTFs 每分鐘、代碼異味數(shù)量、漏洞數(shù)量、測(cè)試覆蓋率、文檔覆蓋率，以及用于棄用組件、計(jì)劃外工作、修復(fù)缺陷的工作量和清償技術(shù)債務(wù)的估算工作量。這些指標(biāo)并非唯一選擇，團(tuán)隊(duì)可以根據(jù)自身需求設(shè)計(jì)更合適的指標(biāo)。

關(guān)注我，緊跟本系列專欄文章，咱們下篇再續(xù)！

★ 作者簡(jiǎn)介：魔都架構(gòu)師，多家大廠后端一線研發(fā)經(jīng)驗(yàn)，在分布式系統(tǒng)設(shè)計(jì)、數(shù)據(jù)平臺(tái)架構(gòu)和AI應(yīng)用開(kāi)發(fā)等領(lǐng)域都有豐富實(shí)踐經(jīng)驗(yàn)。 各大技術(shù)社區(qū)頭部專家博主。具有豐富的引領(lǐng)團(tuán)隊(duì)經(jīng)驗(yàn)，深厚業(yè)務(wù)架構(gòu)和解決方案的積累。 負(fù)責(zé)： 中央/分銷預(yù)訂系統(tǒng)性能優(yōu)化 活動(dòng)&券等營(yíng)銷中臺(tái)建設(shè) 交易平臺(tái)及數(shù)據(jù)中臺(tái)等架構(gòu)和開(kāi)發(fā)設(shè)計(jì) 車聯(lián)網(wǎng)核心平臺(tái)-物聯(lián)網(wǎng)連接平臺(tái)、大數(shù)據(jù)平臺(tái)架構(gòu)設(shè)計(jì)及優(yōu)化 LLM Agent應(yīng)用開(kāi)發(fā) 區(qū)塊鏈應(yīng)用開(kāi)發(fā) 大數(shù)據(jù)開(kāi)發(fā)挖掘經(jīng)驗(yàn) 推薦系統(tǒng)項(xiàng)目 目前主攻市級(jí)軟件項(xiàng)目設(shè)計(jì)、構(gòu)建服務(wù)全社會(huì)的應(yīng)用系統(tǒng)。 ”

參考：

• 編程嚴(yán)選網(wǎng)

編程嚴(yán)選網(wǎng)：http://www.javaedge.cn/ 專注分享軟件開(kāi)發(fā)全生態(tài)相關(guān)技術(shù)文章、視頻教程資源、熱點(diǎn)資訊等，全站資源免費(fèi)學(xué)習(xí)，快來(lái)看看吧~ 【編程嚴(yán)選】星球

歡迎長(zhǎng)按圖片加好友，我會(huì)第一時(shí)間和你分享軟件行業(yè)趨勢(shì)，面試資源，學(xué)習(xí)方法等等。

添加好友備注【技術(shù)群交流】拉你進(jìn)技術(shù)交流群

關(guān)注公眾號(hào)后，在后臺(tái)私信：

• 更多教程資源應(yīng)有盡有，歡迎關(guān)注并加技術(shù)交流群，慢慢獲取

• 為避免大量資源被收藏白嫖而浪費(fèi)各自精力，以上資源領(lǐng)取分別需要收取1元門檻費(fèi)！