阿里巴巴技術質量

讀完需要

6

分鐘

速讀僅需 2 分鐘

阿里 QA 導讀：先快速上線、沒時間改、再緩一緩吧、以后再解決、先用臨時方案處理……埋下的坑越來越多，不知道哪天哪位同學會踩上一顆雷。
特別贊同“人最大的恐懼就是未知，當技術債可說不可見的時候，才是最讓人不想解決的時候。”

作為一個程序員，我們反對復制粘貼，但是我們經常見到相似的代碼到處都是，相同的二方包多個版本，整個代碼庫復制，似而不同的應用比比皆是。當新人加入團隊，老人總要頂著新人鄙夷的目光解釋當初因為什么原因系統設計的如此丑陋。一邊是產品經理突然心血來潮的需求變動讓人暴跳如雷，一邊遺留代碼和遺留系統讓人望而生畏，直到有一天整個崩潰，也不知道鍋落誰家。

漸漸的我們學會了用技術債當借口“之前欠了太多債，所以開發慢，歷史遺留問題，我也沒辦法”，漸漸我們失去了對開發熱愛的靈魂，只剩下痛苦而緩慢的完成業務的軀殼。

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

1

? ?

技術債是什么?

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

經濟債務可能很容易衡量，包括具體需要歸還多少本金和利息。而技術債更像不規范的高利貸，不僅不容易衡量，而且很容易陷入無限還債的深淵。

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

所以技術債本身是對項目或者代碼質量的重要衡量指標。

2

? ?

技術債的惡性循環

• 首先，技術債肯定會不斷地降低開發效率，每加一個功能都困難重重，進而拖慢業務進度。

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

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

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

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

3

? ?

技術債是如何產生的？

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

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

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

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

4

? ?

如何解決技術債

4.1

? ?

讓技術債可衡量是解決技術債的第一步

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

jarchitect 是一款根據一定的規則，評估代碼技術債的工具。可以在平時開發中，不斷的觀察技術債的變化。

同時因為很多“復制-粘貼式”代碼是跨代碼庫的，所以評估工具也只能參考，最好能夠多倉庫橫向對比

4.2

? ?

解決技術債的方案

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

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

4.3

? ?

最后，請不要再引入技術債

可以參考技術債產生的原因，所有的因素都是想法的偏差，只要調整正確的態度，技術債就是可以規避的。

5

? ?

我在阿里五年的技術債解決經歷

回想我加入阿里的五年時間，第一個系統就是在做這個系統重寫的遷移，老的系統已經嚴重導致業務發展遲緩，這時候用到的就是“破產清算”，系統重寫的方式。

后面做另一個系統，隨著產品的增多，應用不斷增加，最后我們用一個應用承接了所有業務，將老的應用全部下線，做了整個向后兼容的遷移。

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

本文引用：

[1]https://www.monkeyuser.com

[2]https://www.jarchitect.com

[3]https://daedtech.com/5-things-ive-learned-in-20-years-of-programming

擴展閱讀

? ?

架構師成長系列

Erik Dietrich：二十年的編程，教會我的五件事！ 2020-09-22

支付寶研究員兼OceanBase總架構師楊傳輝：我在數據庫夢之隊的十年成長路2020-09-21

Mobvista首席架構師蔡超：工作感悟之失敗與成功，我的8點總結2020-09-20

奈學教育CEO孫玄：成為一個有情懷的工程師，我的12點思考2020-09-19

架構師，是否需要寫代碼？2020-09-18

Netstars CTO陳斌：架構師的成長之路2020-09-17

阿里技術專家麒燁：修煉測試基本功2020-09-16

愛奇藝數據中臺負責人馬金韜：數據中臺建設與應用2020-09-14

數之聯CTO方育柯：技術的意義在于成就他人2020-09-13

東方證券首席架構師樊建：企業微服務架構轉型實踐2020-09-12

紅帽資深解決方案架構師魏新宇：云原生應用構建之路2020-09-10

蘇寧智能 BU大數據中心數據治理團隊負責人韋真：數據治理“三字經”，超實用！2020-09-09

螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護隱私的共享智能？2020-09-08

阿里高級技術專家簫逸：如何畫好一張架構圖？2020-09-07

阿里巴巴閑魚架構負責人王樹彬：萬億交易規模技術架構實踐2020-09-05

58轉轉技術總監駱俊武：監控系統選型？必讀本篇！2020-09-04

螞蟻集團高級架構師郭援非：分布式數據庫是金融機構數字化轉型的最佳路徑2020-09-03

工行高級經理林承軍：工行基于 MySQL 構建分布式架構的轉型之路2020-09-02

平安銀行吳建峰：RocketMQ 在銀行的應用和實踐2020-09-01

阿里高級技術專家張建飛：應用架構分離業務邏輯和技術細節之道2020-08-31

? ?END ? ?? #接力技術，鏈接價值#

點分享點點贊點在看

總結

以上是生活随笔為你收集整理的阿里技术专家都铎：一文搞懂技术债的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。