作者 | Ryan Donovan

編譯 | 徐杰承

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

這里的一個(gè)例子是，F(xiàn)acebook最初是用PHP編寫的。然而隨著增加特性、復(fù)雜性和規(guī)模，PHP開始變得不再適用于新的需求，這便是PHP給Facebook帶來的技術(shù)債。但值得注意的是，技術(shù)債并不一定意味著最初的選擇是錯(cuò)誤的。用PHP編寫網(wǎng)站起初是一個(gè)明智的決定——問題并不出在語言，而是需求的改變。

事實(shí)上，不僅是語言，工具、框架、軟件架構(gòu)這些都有可能會(huì)產(chǎn)生技術(shù)債。這在當(dāng)時(shí)可能是為了眼前的利益而做出的善意的編碼決策，但這不意味著它們將一直適用。對(duì)企業(yè)而言，越早解決技術(shù)債問題越好，這將有利于企業(yè)的持續(xù)高速發(fā)展。但解決這些問題需要進(jìn)一步挖掘技術(shù)債的本質(zhì)，并準(zhǔn)確量化你的工程團(tuán)隊(duì)到底背負(fù)了多少債務(wù)。

1、維護(hù)成本

雖然開發(fā)人員喜歡解決問題，但這并不總是意味著他們喜歡尋找技術(shù)債所帶來的bug。技術(shù)領(lǐng)導(dǎo)需要更多的考慮為業(yè)務(wù)服務(wù)，因?yàn)闃I(yè)務(wù)通常關(guān)乎公司的利潤和損失。因此，為了還清技術(shù)債，你首先需要從成本和收益的角度來考慮。 

技術(shù)債的經(jīng)濟(jì)影響是真實(shí)的。根據(jù)Stripe在2018年的研究，他們發(fā)現(xiàn)，開發(fā)人員平均每周會(huì)因技術(shù)債帶來的問題花費(fèi)13.5小時(shí)，如果你用開發(fā)者的工資乘以這個(gè)數(shù)，那么你就可以基本判斷技術(shù)債的成本。

圖片

如同有人在Stack Overflow上所說，“由于復(fù)雜性，低質(zhì)量的代碼通常需要更長時(shí)間來維護(hù)，這將嚴(yán)重影響開發(fā)者所產(chǎn)生的價(jià)值?！贝蠖鄶?shù)公司都已經(jīng)使用了某些問題跟蹤系統(tǒng)，因此評(píng)估花費(fèi)在維護(hù)技術(shù)債上的時(shí)間其實(shí)并不困難。

而要確定特定領(lǐng)域債務(wù)的影響，則需要審查代碼，跟蹤哪些代碼獲得了最多的修改。進(jìn)行這樣的數(shù)據(jù)挖掘還可以讓你識(shí)別出代碼維護(hù)時(shí)的聚類，并將其與跟蹤系統(tǒng)中的錯(cuò)誤完成情況進(jìn)行比較。

當(dāng)然，你也可以直接詢問團(tuán)隊(duì)。Stack Overflow的工程總監(jiān)Roberta Arcoverde說，“這聽起來可能很天真，但這背后確有實(shí)際依據(jù)，如果團(tuán)隊(duì)一致認(rèn)為某個(gè)東西很重要，但這部分因?yàn)榇a或其他問題導(dǎo)致維護(hù)困難，那么你就可以基本定位問題所在?！?/p>

2、機(jī)會(huì)成本

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

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

這需要權(quán)衡開發(fā)者的生產(chǎn)力與業(yè)務(wù)需求量。因?yàn)殡S著代碼變得越來越難維護(hù)，新特性的發(fā)布時(shí)間也越來越長。而代碼庫中需要修改的地方越多，花費(fèi)的時(shí)間就越多。

有時(shí)技術(shù)債來自過時(shí)的或基于以前版本軟件的善意技術(shù)決策。更新這些可能需要大量的代碼重寫而不是簡單的重構(gòu)。雖然一些度量標(biāo)準(zhǔn)會(huì)有所幫助，但如果這與緊急的業(yè)務(wù)需求沖突，還是要根據(jù)實(shí)際情況進(jìn)行決策。

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

3、人力成本

詳細(xì)的文檔、流程以及代碼庫的可讀性非常重要。所有人都知道在某個(gè)時(shí)候你會(huì)需要它，但很多企業(yè)在早期為了省事而跳過了它。這使得新員工必須四處打聽，并占用高級(jí)工程師的時(shí)間，以便讓自己能夠開始工作。

一旦開發(fā)人員準(zhǔn)備好開始工作，他們可能會(huì)因?yàn)榘l(fā)現(xiàn)自己面對(duì)堆積如山的雜亂代碼而感到沮喪——他們不得不花大量時(shí)間試圖弄清楚這段代碼到底想要表達(dá)什么。

此外，過時(shí)或低效的工具和依賴也會(huì)讓開發(fā)人員絕望。想象一下，當(dāng)你在編寫代碼時(shí)發(fā)現(xiàn)一個(gè)令人困惑的古老漏洞?！拔乙詾檫@個(gè)問題在Y版本中已經(jīng)解決了？”“是的，但是我們?nèi)匀辉谑褂肵版本，升級(jí)尚未獲得批準(zhǔn)?！?/p>

而當(dāng)開發(fā)者在工作中無法接觸先進(jìn)技術(shù)棧時(shí)，他們的技能會(huì)逐漸萎縮。在一份調(diào)查中顯示，30%以上的人(取決于地區(qū))表示，他們認(rèn)為自己所在企業(yè)的技術(shù)棧有些過時(shí)，希望尋找使用新技術(shù)的新工作。

這些問題都會(huì)導(dǎo)致企業(yè)員工的流失。如果你的公司總是遭受頻繁的人員流失，這會(huì)對(duì)企業(yè)帶來很大的負(fù)面影響。如果這些債務(wù)讓你失去了優(yōu)秀的員工，那么你將很難在下一次競爭中取得先機(jī)。

4、清點(diǎn)技術(shù)債

技術(shù)債的概念如今已經(jīng)受到了越來越多的關(guān)注，它將工程問題轉(zhuǎn)化為商業(yè)語言。如果你想償還這些債務(wù)，那么你需要用商業(yè)語言來說明。費(fèi)用是多少？它是如何對(duì)企業(yè)帶來影響的？對(duì)于任何商業(yè)決策來說，權(quán)衡都是最重要的。 

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

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