關(guān)于技術(shù)債的思考

????在快速變化的互聯(lián)網(wǎng)環(huán)境下，軟件產(chǎn)品團隊如何在質(zhì)量和速度上取得平衡？如何讓軟件產(chǎn)品以最快的速度抵達用戶手中，使團隊得到最快速的反饋？交付質(zhì)量與速度是否存在一定的平衡？如何在滿足質(zhì)量的前提下快速交付產(chǎn)品價值？這里每一個問題都是工程效能領(lǐng)域的經(jīng)典問題？工程效能的提升涉及方方面面，今天我們只來探討一下關(guān)于技術(shù)債在軟件高效的持續(xù)交付過程當(dāng)中扮演了什么樣的角色，同時也深入了解下它對高效持續(xù)交付的影響和我們應(yīng)該怎么面對它？

關(guān)于交付質(zhì)量與速度是否存在一定平衡這個問題，在持續(xù)交付2.0這本書里，作者喬梁給出了一個肯定的答案：質(zhì)量與速度根本不存在平衡，只有在產(chǎn)品能夠承受的一定質(zhì)量水準(zhǔn)基礎(chǔ)上，追求交付的速度才有意義。

????技術(shù)債指的是過往積累的低質(zhì)量工作對當(dāng)下工作進展造成損害的現(xiàn)象。技術(shù)債是一種軟件缺陷，最有代表性的應(yīng)該是程序源碼中隨時間累計而變得無用的過時垃圾程序代碼。

????技術(shù)債涉及的范圍很廣，可以是質(zhì)量不好的代碼、劣質(zhì)的設(shè)計、脆弱的測試集、不恰當(dāng)?shù)臎Q策、不穩(wěn)定的構(gòu)建環(huán)境、笨重的手工流程等任何因為短期利益而犧牲長期生產(chǎn)效率的東西。

????存在大量技術(shù)債務(wù)的系統(tǒng)，工程師需要花費更多的時間理解如何做出更改，同時提升了犯錯誤的概率。如果發(fā)現(xiàn)問題，則需要花費更多的時間去定位和解決它們。如果沒有發(fā)現(xiàn)這些問題，就會遇到生產(chǎn)故障，以后會花更多的時間來修復(fù)它們。技術(shù)債務(wù)的積累，使任何一個微小的改動都需要花費數(shù)周的時間。

????對于全新的項目，團隊可以從一開始就避免技術(shù)債累計；對遺留項目，團隊除了接過已經(jīng)存在的技術(shù)債往往別無他選。但無論是哪種項目，如果團隊不能管理好技術(shù)債，團隊的效率就會逐漸下降。

????技術(shù)債在技術(shù)方和業(yè)務(wù)方的交流討論中是一個很好的隱喻。業(yè)務(wù)方嘗嘗認識不到持續(xù)拖欠技術(shù)債的成本，而技術(shù)方則嘗嘗意識不到（短期技術(shù)債能帶來的）業(yè)務(wù)價值。在某些情況下，主動選擇拖欠技術(shù)債是一個合理的業(yè)務(wù)決策，有時則不是。引入債務(wù)的概念使得業(yè)務(wù)方和技術(shù)方可以共享彼此的一些顧慮，促使團隊就是否選擇欠債、何時欠債，以及何時需要還債、以何種方式進行還債等問題做出更好的決策。

映射到我們?nèi)粘９ぷ髦校鋵嵕褪钱a(chǎn)品經(jīng)理或者業(yè)務(wù)方只關(guān)注需求的上線時間，到研發(fā)環(huán)節(jié)基本上都是到排期，同時為了滿足時效性還需要犧牲一些質(zhì)量，欠下的質(zhì)量債務(wù)和損失優(yōu)雅的設(shè)計換來上線時間。業(yè)務(wù)方即使意識到對研發(fā)是有侵害的，但由于屁股決定腦袋理論，也不會去過多的在意。

????我們其實還可以把上面的各種類型技術(shù)債按照出現(xiàn)的頻率進行一個等級劃分，并制定針對不同等級的應(yīng)對原則：

以下摘自左耳朵耗子的一遍文章，我們借鑒其第八原則：

https://coolshell.cn/articles/21672.html#原則八：不要遷就老舊系統(tǒng)的技術(shù)債務(wù)

我發(fā)現(xiàn)很多公司都很非常大的技術(shù)債務(wù)，這些債務(wù)具體表現(xiàn)如下：?

• 使用老舊的技術(shù)。比如，使用HTTP1.0， Java 1.6，Websphere，ESB，基于 socket的通訊協(xié)議，過時的模型……等等

• 不合理的設(shè)計。比如，在 gateway 中寫大量的業(yè)務(wù)邏輯，單體架構(gòu)，數(shù)據(jù)和業(yè)務(wù)邏輯深度耦合，錯誤的系統(tǒng)架構(gòu)（把緩存當(dāng)數(shù)據(jù)庫，用消息隊列同步數(shù)據(jù)）……等等

• 缺少配套設(shè)施。比如，沒有自動化測試，沒有好的軟件文檔，沒有質(zhì)量好的代碼，沒有標(biāo)準(zhǔn)和規(guī)范……等等

來找我尋求技術(shù)幫助的人都有各種各樣的問題。我都會對他們苦口婆心地說同樣的一句話——“如果你是來找我 case-by-case 解決問題，我興趣不大，因為，你們千萬不要寄希望能夠很簡單的把一輛夏利車改成一輛法拉利跑車，或是把一棟地基沒打好的歪樓搞正。以前欠下的技術(shù)債，都得要還，沒打好的地基要重新打，沒建配套設(shè)施都要建。這些基礎(chǔ)設(shè)施如果不按照正確科學(xué)的方式建立的話，你是不可能有一個好的的系統(tǒng)，我也沒辦法幫你 case-by-case 的解決問題……”，一開始，他們都會對我說，沒問題，我們就是要還債，但是，最后發(fā)現(xiàn)要還的債真多，有點承受不了，就開始現(xiàn)原形了。?

他們開始為自己的“欠的技術(shù)債”找各種合理化的理由——給你解釋各種各樣的歷史原因和不得以而為之的理由。談著談著，讓我有一種感覺——他們希望得到一種什么都不改什么都不付出的方式就可以進步的心態(tài)，他們寧可讓新的技術(shù) low 下來遷就于這些技術(shù)債，把新的技術(shù)濫用地亂七八糟的。有一個公司，他們的系統(tǒng)架構(gòu)和技術(shù)選型基本都搞錯了，使用錯誤的模型構(gòu)建系統(tǒng)，導(dǎo)致整個系統(tǒng)的性能非常之差，也才幾千萬條數(shù)據(jù)，但他們想的不是還債，不是把地基和配套設(shè)施建好，而且要把樓修的更高，上更多的系統(tǒng)——他們覺得現(xiàn)有的系統(tǒng)挺好，性能問題的原因是他們沒一個大數(shù)據(jù)平臺，所以要建大數(shù)據(jù)平臺……?

我見過很多很多公司，包括大如 BAT 這樣的公司，都會在原來的技術(shù)債上進行更多的建設(shè)，然后，技術(shù)債越來越大，利息越來越大，最終成為一個高利貸，再也還不了（我在《開發(fā)團隊的效率》一文中講過一個 WatchDog 的架構(gòu)模式，一個系統(tǒng)爛了，不是去改這個系統(tǒng)，而是在旁邊建一個系統(tǒng)來看著它，我很難理解為什么會有這樣的邏輯，也許是為了要解決更多的就業(yè)……）?

這里有幾個原則和方法我是非常堅持的，分享給大家：?

• 與其花大力氣遷就技術(shù)債務(wù)，不如直接還技術(shù)債。是所謂的長痛不如短痛。

• 建設(shè)沒有技術(shù)債的“新城區(qū)”，并通過“防腐層?”的架構(gòu)模型，不要讓技術(shù)債侵入“新城區(qū)”。