[[313402]]

作為一名技術(shù)人，你常常會聽到這樣的話：

“先快速上線”

“沒時間改”

“再緩一緩吧”

“以后再解決”

“先用臨時方案處理”

……

當你埋下的坑越來越多，不知道哪天哪位同學(xué)就會踩上一顆雷。特別贊同“人最大的恐懼就是未知，當技術(shù)債可說不可見的時候，才是最讓人不想解決的時候。”

作為一個程序員，我們反對復(fù)制粘貼，但是我們經(jīng)常會見到相似的代碼，相同的二方包，甚至整個代碼庫復(fù)制，似而不同的應(yīng)用比比皆是。

圖片來源：https://www.monkeyuser.com/

當新人加入團隊，老人總要頂著新人鄙夷的目光解釋：當初是什么原因，才導(dǎo)致系統(tǒng)設(shè)計得如此丑陋。一邊是產(chǎn)品經(jīng)理突然心血來潮的需求變動讓人暴跳如雷，一邊遺留代碼和遺留系統(tǒng)讓人望而生畏，直到有一天整個崩潰，也不知道鍋落誰家。

漸漸地，我們學(xué)會了用技術(shù)債當借口。“之前欠了太多債，所以開發(fā)慢”、“歷史遺留問題，我也沒辦法”，后來，我們失去了熱愛開發(fā)的靈魂，只剩下痛苦而緩慢的完成業(yè)務(wù)的軀殼。

這些背后都是技術(shù)債帶來的問題。然而，作為程序員的我們，當我們聽到《沒有理想的人不傷心》中“我不要在失敗孤獨中死去”，我們還是會熱血沸騰，還會想要迎難而上，所以，今天就讓我們搞懂技術(shù)債，進而搞定技術(shù)債。

一、技術(shù)債是什么?

“技術(shù)債”是1992年被沃德·坎寧安提出來。在金融領(lǐng)域通過短期的借貸獲得充足的資金加快發(fā)展，代價就是除了本金之外還要付出利息。軟件領(lǐng)域也是一樣，為了盡快上線，暫時不顧代碼質(zhì)量，從而欠下技術(shù)債。而后續(xù)的開發(fā)持續(xù)降低開發(fā)效率，就像還利息一樣。

經(jīng)濟債務(wù)相對容易衡量，只需要計算歸還多少本金和利息。而技術(shù)債更像不規(guī)范的高利貸，不僅不容易衡量，而且很容易陷入無限還債的深淵。

我們經(jīng)常會把代碼稱之為寶貴的資產(chǎn)，因為技術(shù)債在代碼層面的普遍存在，所以我們也可以說，代碼就是債務(wù)。只要你是程序員，可以說你的一生都會被技術(shù)債所影響。

所以，技術(shù)債本身是對項目或者代碼質(zhì)量的重要衡量指標。

二、 技術(shù)債的惡性循環(huán)

[[313404]]

首先，技術(shù)債肯定會不斷地降低開發(fā)效率，每加一個功能都困難重重，進而拖慢業(yè)務(wù)進度。

之后，業(yè)務(wù)上的挫敗感會給程序員自身帶來更大的挫敗感。就像每天被人上門討債的負債者，當楊白勞的滋味相信沒人喜歡。

再之后，團隊開始無休無止的爭論，新人想要改革，老人害怕風險，每個人固守自己的業(yè)務(wù)不敢接受升級，N變更帶來的N*N的風險，沒人愿意承擔。

在這之后，長期技術(shù)不升級導(dǎo)致技術(shù)落后，這個團隊的技術(shù)競爭力下降，每個人都能感受到團隊無論是技術(shù)能力還是商業(yè)價值都在下降，進而導(dǎo)致更大的挫敗感。

最終，上面這些問題還是會反過來影響業(yè)務(wù)，影響商業(yè)價值，讓整個團隊陷入惡性循環(huán)之中，最怕人才流失，又讓新人更難融入。當團隊(公司)業(yè)務(wù)(商業(yè))價值降到最低的時候，也就是宣告解散(破產(chǎn))的時候。

三、技術(shù)債是如何產(chǎn)生的?

“復(fù)制-粘貼式開發(fā)模式。” 技術(shù)債的認為感知是有延遲的，就像你在高速上超速開車，直到一周后你收到罰單，才知道自己要付出代價。很多團隊不顧后果的復(fù)制粘貼，直到體會到業(yè)務(wù)發(fā)展緩慢，但是已經(jīng)來不及了。

“我們必須馬上上線。” 技術(shù)界流傳最廣的三大借口：“我們的領(lǐng)域非常復(fù)雜，所以我們有很陡峭的學(xué)習曲線”、“我們的情況特殊，所以沒辦法寫單元測試”、“我們時間緊急，必須盡快上線”。首先這些假設(shè)從來沒被證明過，其次假設(shè)“我們時間緊迫，所以必須犧牲質(zhì)量”成立，但是不代表著“犧牲質(zhì)量就能趕時間”。最后，在一個必須馬上上線的論調(diào)充斥的團隊中，那些想要做更多重構(gòu)和更優(yōu)設(shè)計的人會有深深地負罪感，陷入不斷創(chuàng)造技術(shù)債的怪圈。

“我們暫時趕一下進度，后面再重構(gòu)。” 如果能夠經(jīng)過合理分析，為了短時間趕工做出一定的犧牲，后面再有計劃地重構(gòu)升級，技術(shù)債本身并不一定是全是壞事。但是很多時候這句話成了空頭支票，最后，就是變成了上一種惡性循環(huán)。

“解決問題的最好辦法是寫代碼。” 我們最喜歡的一句話就是“用代碼改變世界”。但是恰恰相反的是，如果能夠不寫代碼就能解決問題，才是最好辦法。我們喜歡崇拜代碼量，但是無休止的復(fù)制黏貼帶來的大量代碼不但沒有價值，反而帶來更大的成本。

四、如何解決技術(shù)債

讓技術(shù)債可衡量是解決技術(shù)債的第一步

根據(jù)觀察者效應(yīng)，將問題暴露出來本身就是一種解決問題的辦法。人最大的恐懼就是未知，當技術(shù)債可說不可見的時候，才是最讓人不想解決的時候。

1、Jarchitect是一款根據(jù)一定的規(guī)則，評估代碼技術(shù)債的工具?？梢栽谄綍r開發(fā)中，不斷的觀察技術(shù)債的變化。

圖片來源：https://www.jarchitect.com/

2、同時因為很多“復(fù)制-粘貼式”代碼是跨代碼庫的，所以評估工具也只能參考，最好能夠多倉庫橫向?qū)Ρ取?/p>

解決技術(shù)債的方案

直接宣布破產(chǎn)(整個重寫)：下線老的系統(tǒng)，用新的系統(tǒng)替代，很多團隊都這么干過。尤其當你接手了一個很老的遺留系統(tǒng)，維護成本高，新特性需求積壓嚴重，用新的系統(tǒng)替代可能是更好的辦法

向后兼容的不斷遷移：新做一個系統(tǒng)兼容老的功能，或者直接在老的系統(tǒng)中直接加入新的流程，在測試用例的保證下，將功能隨著業(yè)務(wù)升級一點一點的遷移，慢慢放棄老的系統(tǒng)，刪掉代碼，最后完成整個升級，將技術(shù)債像手術(shù)一樣切除掉。

最后，請不要再引入技術(shù)債

可以參考技術(shù)債產(chǎn)生的原因，所有的因素都是想法的偏差，只要調(diào)整正確的態(tài)度，技術(shù)債就是可以規(guī)避的。

五、我在阿里五年的技術(shù)債解決經(jīng)歷

回想我加入阿里的五年時間，第一個系統(tǒng)就是在做這個系統(tǒng)重寫的遷移，老的系統(tǒng)已經(jīng)嚴重導(dǎo)致業(yè)務(wù)發(fā)展遲緩，這時候用到的就是“破產(chǎn)清算”，系統(tǒng)重寫的方式。

后面做另一個系統(tǒng)，隨著產(chǎn)品的增多，應(yīng)用不斷增加，最后我們用一個應(yīng)用承接了所有業(yè)務(wù)，將老的應(yīng)用全部下線，做了整個向后兼容的遷移。

后記

最近讀了一篇文章《二十年的編程，教會我的五件事》，發(fā)現(xiàn)作者作為一個咨詢師的角度在幾年的時間內(nèi)寫了很多關(guān)于軟件項目的文章，其中幾篇技術(shù)債的文章以我的英語讀起來很困難，所以為了搞懂技術(shù)債，決定邊翻譯邊學(xué)習。

本文引用：[1]https://www.monkeyuser.com[2]https://www.jarchitect.com[3]https://daedtech.com/5-things-ive-learned-in-20-years-of-programming