關于技術(shù)債的思考
????在快速變化的互聯(lián)網(wǎng)環(huán)境下，軟件產(chǎn)品團隊如何在質(zhì)量和速度上取得平衡？如何讓軟件產(chǎn)品以最快的速度抵達用戶手中，使團隊得到最快速的反饋？交付質(zhì)量與速度是否存在一定的平衡？如何在滿足質(zhì)量的前提下快速交付產(chǎn)品價值？這里每一個問題都是工程效能領域的經(jīng)典問題？工程效能的提升涉及方方面面，今天我們只來探討一下關于技術(shù)債在軟件高效的持續(xù)交付過程當中扮演了什么樣的角色，同時也深入了解下它對高效持續(xù)交付的影響和我們應該怎么面對它？
關于交付質(zhì)量與速度是否存在一定平衡這個問題，在持續(xù)交付2.0這本書里，作者喬梁給出了一個肯定的答案：質(zhì)量與速度根本不存在平衡，只有在產(chǎn)品能夠承受的一定質(zhì)量水準基礎上，追求交付的速度才有意義。????技術(shù)債指的是過往積累的低質(zhì)量工作對當下工作進展造成損害的現(xiàn)象。技術(shù)債是一種軟件缺陷，最有代表性的應該是程序源碼中隨時間累計而變得無用的過時垃圾程序代碼。
????技術(shù)債涉及的范圍很廣，可以是質(zhì)量不好的代碼、劣質(zhì)的設計、脆弱的測試集、不恰當?shù)臎Q策、不穩(wěn)定的構(gòu)建環(huán)境、笨重的手工流程等任何因為短期利益而犧牲長期生產(chǎn)效率的東西。
技術(shù)債帶來的影響????存在大量技術(shù)債務的系統(tǒng)，工程師需要花費更多的時間理解如何做出更改，同時提升了犯錯誤的概率。如果發(fā)現(xiàn)問題，則需要花費更多的時間去定位和解決它們。如果沒有發(fā)現(xiàn)這些問題，就會遇到生產(chǎn)故障，以后會花更多的時間來修復它們。技術(shù)債務的積累，使任何一個微小的改動都需要花費數(shù)周的時間。
????對于全新的項目，團隊可以從一開始就避免技術(shù)債累計；對遺留項目，團隊除了接過已經(jīng)存在的技術(shù)債往往別無他選。但無論是哪種項目，如果團隊不能管理好技術(shù)債，團隊的效率就會逐漸下降。
????技術(shù)債在技術(shù)方和業(yè)務方的交流討論中是一個很好的隱喻。業(yè)務方嘗嘗認識不到持續(xù)拖欠技術(shù)債的成本，而技術(shù)方則嘗嘗意識不到（短期技術(shù)債能帶來的）業(yè)務價值。在某些情況下，主動選擇拖欠技術(shù)債是一個合理的業(yè)務決策，有時則不是。引入債務的概念使得業(yè)務方和技術(shù)方可以共享彼此的一些顧慮，促使團隊就是否選擇欠債、何時欠債，以及何時需要還債、以何種方式進行還債等問題做出更好的決策。
映射到我們?nèi)粘９ぷ髦校鋵嵕褪钱a(chǎn)品經(jīng)理或者業(yè)務方只關注需求的上線時間，到研發(fā)環(huán)節(jié)基本上都是到排期，同時為了滿足時效性還需要犧牲一些質(zhì)量，欠下的質(zhì)量債務和損失優(yōu)雅的設計換來上線時間。業(yè)務方即使意識到對研發(fā)是有侵害的，但由于屁股決定腦袋理論，也不會去過多的在意。
細化技術(shù)債分類| 技術(shù)債類型 | 類型特征 | 類型描述 | 推薦應對方式 |
| 有意欠下的債 | 短期的 | 戰(zhàn)術(shù)性或戰(zhàn)略性的欠債。如為了準時部署一次對時間很敏感的上線。 | 如果有正當?shù)臉I(yè)務必要性可以欠債，但需要盡快還清。 |
| 長期的 | 戰(zhàn)略性的欠債。如一個這樣的決策：僅支持一個平臺，而非從一開始就支持多平臺進行設計和構(gòu)建。 | 如有必要，可以欠債；但需要明確還債的觸發(fā)條件，通常是一期先支持一個平臺，二期擴展還債。 | |
| 無意欠下的債 | 得過且過 | 由于不好的軟件開發(fā)實踐而欠下的債。這類技術(shù)債會拖慢當下和未來的進度，應當避免。 | 一開始就應該通過高質(zhì)量的工作實踐避免這類技術(shù)債。 |
| 難以避免 | 由于軟件開發(fā)易錯的本質(zhì)（設計方案沒有按我們預期發(fā)揮作用或者新版平臺使得我們設計的某些方面嚴重失效了）而偶然欠下的債。 | 這類技術(shù)債其實無法避免，這是由軟件開發(fā)的本質(zhì)所決定的。監(jiān)控這些債務帶來的影響，當債的『利息』變得過高時就需要還債了。通常也是重構(gòu)的觸發(fā)條件。 | |
| 遺留技術(shù)債 | 新團隊從已有代碼庫中繼承下來的技術(shù)債。 | 做好還債計劃，不要讓”歷史問題"成為不還債的借口。 |
????我們其實還可以把上面的各種類型技術(shù)債按照出現(xiàn)的頻率進行一個等級劃分，并制定針對不同等級的應對原則：
以下摘自左耳朵耗子的一遍文章，我們借鑒其第八原則：
https://coolshell.cn/articles/21672.html#原則八：不要遷就老舊系統(tǒng)的技術(shù)債務
我發(fā)現(xiàn)很多公司都很非常大的技術(shù)債務，這些債務具體表現(xiàn)如下：?
使用老舊的技術(shù)。比如，使用HTTP1.0， Java 1.6，Websphere，ESB，基于 socket的通訊協(xié)議，過時的模型……等等
不合理的設計。比如，在 gateway 中寫大量的業(yè)務邏輯，單體架構(gòu)，數(shù)據(jù)和業(yè)務邏輯深度耦合，錯誤的系統(tǒng)架構(gòu)（把緩存當數(shù)據(jù)庫，用消息隊列同步數(shù)據(jù)）……等等
缺少配套設施。比如，沒有自動化測試，沒有好的軟件文檔，沒有質(zhì)量好的代碼，沒有標準和規(guī)范……等等
來找我尋求技術(shù)幫助的人都有各種各樣的問題。我都會對他們苦口婆心地說同樣的一句話——“如果你是來找我 case-by-case 解決問題，我興趣不大，因為，你們千萬不要寄希望能夠很簡單的把一輛夏利車改成一輛法拉利跑車，或是把一棟地基沒打好的歪樓搞正。以前欠下的技術(shù)債，都得要還，沒打好的地基要重新打，沒建配套設施都要建。這些基礎設施如果不按照正確科學的方式建立的話，你是不可能有一個好的的系統(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)，導致整個系統(tǒng)的性能非常之差，也才幾千萬條數(shù)據(jù)，但他們想的不是還債，不是把地基和配套設施建好，而且要把樓修的更高，上更多的系統(tǒng)——他們覺得現(xiàn)有的系統(tǒng)挺好，性能問題的原因是他們沒一個大數(shù)據(jù)平臺，所以要建大數(shù)據(jù)平臺……?
我見過很多很多公司，包括大如 BAT 這樣的公司，都會在原來的技術(shù)債上進行更多的建設，然后，技術(shù)債越來越大，利息越來越大，最終成為一個高利貸，再也還不了（我在《開發(fā)團隊的效率》一文中講過一個 WatchDog 的架構(gòu)模式，一個系統(tǒng)爛了，不是去改這個系統(tǒng)，而是在旁邊建一個系統(tǒng)來看著它，我很難理解為什么會有這樣的邏輯，也許是為了要解決更多的就業(yè)……）?
這里有幾個原則和方法我是非常堅持的，分享給大家：?
與其花大力氣遷就技術(shù)債務，不如直接還技術(shù)債。是所謂的長痛不如短痛。
建設沒有技術(shù)債的“新城區(qū)”，并通過“防腐層?”的架構(gòu)模型，不要讓技術(shù)債侵入“新城區(qū)”。