入職阿里5年，他如何破解「技術債」？

簡介： 做者 | 都鐸

做爲一名技術人，你經常會聽到這樣的話：

「先快速上線」
「沒時間改」
「再緩一緩吧」
「之後再解決」
「先用臨時方案處理」
……

當你埋下的坑愈來愈多，不知道哪天哪位同窗就會踩上一顆雷。特別贊同「人最大的恐懼就是未知，當技術債可說不可見的時候，纔是最讓人不想解決的時候。」

做爲一個程序員，咱們反對複製粘貼，可是咱們常常會見到類似的代碼，相同的二方包，甚至整個代碼庫複製，似而不一樣的應用比比皆是。

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

當新人加入團隊，老人總要頂着新人鄙夷的目光解釋：當初是什麼緣由，才致使系統設計得如此醜陋。一邊是產品經理忽然心血來潮的需求變更讓人暴跳如雷，一邊遺留代碼和遺留系統讓人望而生畏，直到有一天整個崩潰，也不知道鍋落誰家。

漸漸地，咱們學會了用技術債當藉口。「以前欠了太多債，因此開發慢」、「歷史遺留問題，我也沒辦法」，後來，咱們失去了熱愛開發的靈魂，只剩下痛苦而緩慢的完成業務的軀殼。

這些背後都是技術債帶來的問題。然而，做爲程序員的咱們，當咱們聽到《沒有理想的人不傷心》中「我不要在失敗孤獨中死去」，咱們仍是會熱血沸騰，還會想要迎難而上，因此，今天就讓咱們搞懂技術債，進而搞定技術債。

1、技術債是什麼?

「技術債」是1992年被沃德·坎寧安提出來。在金融領域經過短時間的借貸得到充足的資金加快發展，代價就是除了本金以外還要付出利息。軟件領域也是同樣，爲了儘快上線，暫時不顧代碼質量，從而欠下技術債。然後續的開發持續下降開發效率，就像還利息同樣。

經濟債務相對容易衡量，只須要計算歸還多少本金和利息。而技術債更像不規範的高利貸，不只不容易衡量，並且很容易陷入無限還債的深淵。

咱們常常會把代碼稱之爲寶貴的資產，由於技術債在代碼層面的廣泛存在，因此咱們也能夠說，代碼就是債務。只要你是程序員，能夠說你的一輩子都會被技術債所影響。

因此，技術債自己是對項目或者代碼質量的重要衡量指標。

2、 技術債的惡性循環

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

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

再以後，團隊開始無休無止的爭論，新人想要改革，老人懼怕風險，每一個人固守本身的業務不敢接受升級，N變動帶來的N*N的風險，沒人願意承擔。

在這以後，長期技術不升級致使技術落後，這個團隊的技術競爭力降低，每一個人都能感覺到團隊不管是技術能力仍是商業價值都在降低，進而致使更大的挫敗感。

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

3、技術債是如何產生的？

「複製-粘貼式開發模式。」 技術債的認爲感知是有延遲的，就像你在高速上超速開車，直到一週後你收到罰單，才知道本身要付出代價。不少團隊不顧後果的複製粘貼，直到體會到業務發展緩慢，可是已經來不及了。

「咱們必須立刻上線。」 技術界流傳最廣的三大藉口：「咱們的領域很是複雜，因此咱們有很陡峭的學習曲線」、「咱們的狀況特殊，因此沒辦法寫單元測試」、「咱們時間緊急，必須儘快上線」。首先這些假設歷來沒被證實過，其次假設「咱們時間緊迫，因此必須犧牲質量」成立，可是不表明着「犧牲質量就能趕時間」。最後，在一個必須立刻上線的論調充斥的團隊中，那些想要作更多重構和更優設計的人會有深深地負罪感，陷入不斷創造技術債的怪圈。

「咱們暫時趕一下進度，後面再重構。」 若是可以通過合理分析，爲了短期趕工作出必定的犧牲，後面再有計劃地重構升級，技術債自己並不必定是全是壞事。可是不少時候這句話成了空頭支票，最後，就是變成了上一種惡性循環。

「解決問題的最好辦法是寫代碼。」 咱們最喜歡的一句話就是「用代碼改變世界」。可是偏偏相反的是，若是可以不寫代碼就能解決問題，纔是最好辦法。咱們喜歡崇拜代碼量，可是無休止的複製黏貼帶來的大量代碼不但沒有價值，反而帶來更大的成本。

4、如何解決技術債

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

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

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

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

二、同時由於不少「複製-粘貼式」代碼是跨代碼庫的，因此評估工具也只能參考，最好可以多倉庫橫向對比。

解決技術債的方案

直接宣佈破產（整個重寫）：下線老的系統，用新的系統替代，不少團隊都這麼幹過。尤爲當你接手了一個很老的遺留系統，維護成本高，新特性需求積壓嚴重，用新的系統替代多是更好的辦法
向後兼容的不斷遷移：新作一個系統兼容老的功能，或者直接在老的系統中直接加入新的流程，在測試用例的保證下，將功能隨着業務升級一點一點的遷移，慢慢放棄老的系統，刪掉代碼，最後完成整個升級，將技術債像手術同樣切除掉。

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

能夠參考技術債產生的緣由，全部的因素都是想法的誤差，只要調整正確的態度，技術債就是能夠規避的。

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

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

後面作另外一個系統，隨着產品的增多，應用不斷增長，最後咱們用一個應用承接了全部業務，將老的應用所有下線，作了整個向後兼容的遷移。

後記

最近讀了一篇文章《二十年的編程，教會個人五件事》，發現做者做爲一個諮詢師的角度在幾年的時間內寫了不少關於軟件項目的文章，其中幾篇技術債的文章以個人英語讀起來很困難，因此爲了搞懂技術債，決定邊翻譯邊學習。

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