作者 | Ryan Donovan

編譯 | 徐杰承

當Ward Cunningham在“敏捷宣言”中首次提出“技術債”概念時，他表示需要用一種方式來討論項目早期所做的決策，這些決策會在工程師后續的開發工作中困擾他們。一些企業為了將產品推向市場而在早期做出的技術決策可能并不適用于長期發展，除非修正這些決策，否則團隊的生產力將會受到影響。

這里的一個例子是，Facebook最初是用php編寫的。然而隨著增加特性、復雜性和規模，PHP開始變得不再適用于新的需求，這便是PHP給Facebook帶來的技術債。但值得注意的是，技術債并不一定意味著最初的選擇是錯誤的。用PHP編寫網站起初是一個明智的決定——問題并不出在語言，而是需求的改變。

事實上，不僅是語言，工具、框架、軟件架構這些都有可能會產生技術債。這在當時可能是為了眼前的利益而做出的善意的編碼決策，但這不意味著它們將一直適用。對企業而言，越早解決技術債問題越好，這將有利于企業的持續高速發展。但解決這些問題需要進一步挖掘技術債的本質，并準確量化你的工程團隊到底背負了多少債務。

1、維護成本

雖然開發人員喜歡解決問題，但這并不總是意味著他們喜歡尋找技術債所帶來的bug。技術領導需要更多的考慮為業務服務，因為業務通常關乎公司的利潤和損失。因此，為了還清技術債，你首先需要從成本和收益的角度來考慮。

技術債的經濟影響是真實的。根據Stripe在2018年的研究，他們發現，開發人員平均每周會因技術債帶來的問題花費13.5小時，如果你用開發者的工資乘以這個數，那么你就可以基本判斷技術債的成本。

如同有人在Stack Overflow上所說，“由于復雜性，低質量的代碼通常需要更長時間來維護，這將嚴重影響開發者所產生的價值。”大多數公司都已經使用了某些問題跟蹤系統，因此評估花費在維護技術債上的時間其實并不困難。

而要確定特定領域債務的影響，則需要審查代碼，跟蹤哪些代碼獲得了最多的修改。進行這樣的數據挖掘還可以讓你識別出代碼維護時的聚類，并將其與跟蹤系統中的錯誤完成情況進行比較。

當然，你也可以直接詢問團隊。Stack Overflow的工程總監Roberta Arcoverde說，“這聽起來可能很天真，但這背后確有實際依據，如果團隊一致認為某個東西很重要，但這部分因為代碼或其他問題導致維護困難，那么你就可以基本定位問題所在。”

2、機會成本

如果開發人員將大量時間花在技術債和糟糕的代碼上，這意味著他們沒有多余的精力創新。對于注重速度的軟件行業來說，這是一件大事。你發布新功能的速度越快，就能越好地滿足客戶的需求，也能為產品增加更多的價值。相反，將功能和補丁推向市場花費的時間越多，你就越落后于競爭對手。

任何技術債幾乎都會影響到編寫你要交付的代碼的時間，但從另一個角度看，解決技術債同樣存在著不小的復雜性，這種復雜性本身也會成為一筆債務。因此，技術管理者需要決定到底該在哪個時候解決問題。

這需要權衡開發者的生產力與業務需求量。因為隨著代碼變得越來越難維護，新特性的發布時間也越來越長。而代碼庫中需要修改的地方越多，花費的時間就越多。

有時技術債來自過時的或基于以前版本軟件的善意技術決策。更新這些可能需要大量的代碼重寫而不是簡單的重構。雖然一些度量標準會有所幫助，但如果這與緊急的業務需求沖突，還是要根據實際情況進行決策。

當然如果條件允許，越早解決問題越好。隨著技術債的增長，它會產生“利息”，支付利息將變得越來越繁重，甚至超越“本金”。在一個軟件企業中，隨著技術債務的增長，整體開發速度會越來越慢，交付給客戶的新特性也會越來越少。

3、人力成本

軟件公司一直在激烈爭奪頂級技術人才，這使得尋找和聘用新員工的成本非常高。入職后的前幾周對開發人員非常重要，如果這段時間開發人員對公司產生反感——20%的開發人員在接受角色后的45天內離職。詳細的文檔、流程以及代碼庫的可讀性非常重要。所有人都知道在某個時候你會需要它，但很多企業在早期為了省事而跳過了它。這使得新員工必須四處打聽，并占用高級工程師的時間，以便讓自己能夠開始工作。

一旦開發人員準備好開始工作，他們可能會因為發現自己面對堆積如山的雜亂代碼而感到沮喪——他們不得不花大量時間試圖弄清楚這段代碼到底想要表達什么。

此外，過時或低效的工具和依賴也會讓開發人員絕望。想象一下，當你在編寫代碼時發現一個令人困惑的古老漏洞。“我以為這個問題在Y版本中已經解決了？”“是的，但是我們仍然在使用X版本，升級尚未獲得批準。”

而當開發者在工作中無法接觸先進技術棧時，他們的技能會逐漸萎縮。在一份調查中顯示，30%以上的人(取決于地區)表示，他們認為自己所在企業的技術棧有些過時，希望尋找使用新技術的新工作。

這些問題都會導致企業員工的流失。如果你的公司總是遭受頻繁的人員流失，這會對企業帶來很大的負面影響。如果這些債務讓你失去了優秀的員工，那么你將很難在下一次競爭中取得先機。

4、清點技術債

技術債的概念如今已經受到了越來越多的關注，它將工程問題轉化為商業語言。如果你想償還這些債務，那么你需要用商業語言來說明。費用是多少？它是如何對企業帶來影響的？對于任何商業決策來說，權衡都是最重要的。

像金融債務一樣，當你花費越來越多的時間來解決它的影響時，未償還的技術債務會困擾你。糟糕的代碼會帶來更多糟糕的代碼，這類似利滾利的概念。你并不一定需要在某個時間徹底償還債務，但你需要持續作出改變，削減技術債，你就有更多的空間來編寫真正能夠帶來價值的代碼。

原文鏈接：https://stackoverflow.blog/2023/08/24/if-you-want-to-address-tech-debt-quantify-it-first