入職阿里5年，他如何破解“技術債”？
作為一名技術人，你常常會聽到這樣的話：
“先快速上線”
“沒時間改”
“再緩一緩吧”
“以后再解決”
“先用臨時方案處理”
……
當你埋下的坑越來越多，不知道哪天哪位同學就會踩上一顆雷。特別贊同“人最大的恐懼就是未知，當技術債可說不可見的時候，才是最讓人不想解決的時候。”
作為一個程序員，我們反對復制粘貼，但是我們經常會見到相似的代碼，相同的二方包，甚至整個代碼庫復制，似而不同的應用比比皆是。
圖片來源：https://www.monkeyuser.com/
當新人加入團隊，老人總要頂著新人鄙夷的目光解釋：當初是什么原因，才導致系統設計得如此丑陋。一邊是產品經理突然心血來潮的需求變動讓人暴跳如雷，一邊遺留代碼和遺留系統讓人望而生畏，直到有一天整個崩潰，也不知道鍋落誰家。
漸漸地，我們學會了用技術債當借口。“之前欠了太多債，所以開發慢”、“歷史遺留問題，我也沒辦法”，后來，我們失去了熱愛開發的靈魂，只剩下痛苦而緩慢的完成業務的軀殼。
這些背后都是技術債帶來的問題。然而，作為程序員的我們，當我們聽到《沒有理想的人不傷心》中“我不要在失敗孤獨中死去”，我們還是會熱血沸騰，還會想要迎難而上，所以，今天就讓我們搞懂技術債，進而搞定技術債。
一、技術債是什么?
“技術債”是1992年被沃德·坎寧安提出來。在金融領域通過短期的借貸獲得充足的資金加快發展，代價就是除了本金之外還要付出利息。軟件領域也是一樣，為了盡快上線，暫時不顧代碼質量，從而欠下技術債。而后續的開發持續降低開發效率，就像還利息一樣。
經濟債務相對容易衡量，只需要計算歸還多少本金和利息。而技術債更像不規范的高利貸，不僅不容易衡量，而且很容易陷入無限還債的深淵。
我們經常會把代碼稱之為寶貴的資產，因為技術債在代碼層面的普遍存在，所以我們也可以說，代碼就是債務。只要你是程序員，可以說你的一生都會被技術債所影響。
所以，技術債本身是對項目或者代碼質量的重要衡量指標。
二、 技術債的惡性循環
首先，技術債肯定會不斷地降低開發效率，每加一個功能都困難重重，進而拖慢業務進度。
之后，業務上的挫敗感會給程序員自身帶來更大的挫敗感。就像每天被人上門討債的負債者，當楊白勞的滋味相信沒人喜歡。
再之后，團隊開始無休無止的爭論，新人想要改革，老人害怕風險，每個人固守自己的業務不敢接受升級，N變更帶來的N*N的風險，沒人愿意承擔。
在這之后，長期技術不升級導致技術落后，這個團隊的技術競爭力下降，每個人都能感受到團隊無論是技術能力還是商業價值都在下降，進而導致更大的挫敗感。
最終，上面這些問題還是會反過來影響業務，影響商業價值，讓整個團隊陷入惡性循環之中，最怕人才流失，又讓新人更難融入。當團隊(公司)業務(商業)價值降到最低的時候，也就是宣告解散(破產)的時候。
三、技術債是如何產生的?
“復制-粘貼式開發模式。” 技術債的認為感知是有延遲的，就像你在高速上超速開車，直到一周后你收到罰單，才知道自己要付出代價。很多團隊不顧后果的復制粘貼，直到體會到業務發展緩慢，但是已經來不及了。
“我們必須馬上上線。” 技術界流傳最廣的三大借口：“我們的領域非常復雜，所以我們有很陡峭的學習曲線”、“我們的情況特殊，所以沒辦法寫單元測試”、“我們時間緊急，必須盡快上線”。首先這些假設從來沒被證明過，其次假設“我們時間緊迫，所以必須犧牲質量”成立，但是不代表著“犧牲質量就能趕時間”。最后，在一個必須馬上上線的論調充斥的團隊中，那些想要做更多重構和更優設計的人會有深深地負罪感，陷入不斷創造技術債的怪圈。
“我們暫時趕一下進度，后面再重構。” 如果能夠經過合理分析，為了短時間趕工做出一定的犧牲，后面再有計劃地重構升級，技術債本身并不一定是全是壞事。但是很多時候這句話成了空頭支票，最后，就是變成了上一種惡性循環。
“解決問題的最好辦法是寫代碼。” 我們最喜歡的一句話就是“用代碼改變世界”。但是恰恰相反的是，如果能夠不寫代碼就能解決問題，才是最好辦法。我們喜歡崇拜代碼量，但是無休止的復制黏貼帶來的大量代碼不但沒有價值，反而帶來更大的成本。
四、如何解決技術債
讓技術債可衡量是解決技術債的第一步
根據觀察者效應，將問題暴露出來本身就是一種解決問題的辦法。人最大的恐懼就是未知，當技術債可說不可見的時候，才是最讓人不想解決的時候。
1、Jarchitect是一款根據一定的規則，評估代碼技術債的工具。可以在平時開發中，不斷的觀察技術債的變化。
圖片來源：https://www.jarchitect.com/
2、同時因為很多“復制-粘貼式”代碼是跨代碼庫的，所以評估工具也只能參考，最好能夠多倉庫橫向對比。
解決技術債的方案
直接宣布破產(整個重寫)：下線老的系統，用新的系統替代，很多團隊都這么干過。尤其當你接手了一個很老的遺留系統，維護成本高，新特性需求積壓嚴重，用新的系統替代可能是更好的辦法
向后兼容的不斷遷移：新做一個系統兼容老的功能，或者直接在老的系統中直接加入新的流程，在測試用例的保證下，將功能隨著業務升級一點一點的遷移，慢慢放棄老的系統，刪掉代碼，最后完成整個升級，將技術債像手術一樣切除掉。
最后，請不要再引入技術債
可以參考技術債產生的原因，所有的因素都是想法的偏差，只要調整正確的態度，技術債就是可以規避的。
五、我在阿里五年的技術債解決經歷
回想我加入阿里的五年時間，第一個系統就是在做這個系統重寫的遷移，老的系統已經嚴重導致業務發展遲緩，這時候用到的就是“破產清算”，系統重寫的方式。
后面做另一個系統，隨著產品的增多，應用不斷增加，最后我們用一個應用承接了所有業務，將老的應用全部下線，做了整個向后兼容的遷移。
后記
最近讀了一篇文章《二十年的編程，教會我的五件事》，發現作者作為一個咨詢師的角度在幾年的時間內寫了很多關于軟件項目的文章，其中幾篇技術債的文章以我的英語讀起來很困難，所以為了搞懂技術債，決定邊翻譯邊學習。
本文引用：[1]https://www.monkeyuser.com[2]https://www.jarchitect.com[3]https://daedtech.com/5-things-ive-learned-in-20-years-of-programming
