作者 | 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/