技術債務

背景：最近一直在給研發團隊強調必定要把產品平臺關鍵的帳號系統分離出來，而不是和業務產品線有瓜葛。可是由於涉及改動太大，業務線很忙遲遲獲得不到執行。在這種狀況下，我協調召開了研發的緊急會議，要求務必在近期解決這個問題，甚至不惜減慢業務線的進度。其實若是你們僅僅是由於時間緊、任務重沒法改動我倒不擔憂，我最怕的就是你們認爲這件事情並不嚴重，在我作技術的9年生涯中見證過太屢次由於不重視這種狀況、或者推遲修正形成的更大或者不可挽回的問題，那咱們用2周或者更多時間來修正半年前犯下的錯誤是徹底值得的。

---

       爲何我強烈要求這麼作，具體緣由不作分析，只須要說明咱們是平臺級的產品，帳戶系統是公共組件，若是這些公共組件卻附屬在其中一個或某個業務產品線中，你們就知道咱們後期的靈活性和可擴展性面臨怎樣的困境了。

上面談的這種狀況就屬於技術債務，技術債務的造成每每有兩個主要緣由：

1. 沒有架構能力，對將來可能面臨的糟糕狀況沒有預知；

2. 知道可能後期會面臨問題，可是爲了追求進度，暫時放棄精細化的架構設計；

       對於第一種狀況，很少說，等你發現問題時估計就有些晚了，相應的付出的成本也會更大。因此對軟件爲何咱們經常強調高端的架構能力，而不是僅僅機械的代碼能力。

       第二種狀況其實你們是知道後期可能會遇到的糟糕狀況，可是爲了求快並無進行好的架構設計，在此以後，大多數人會由於心理上的拖延或者生理上的懶惰把重構任務推後，這時技術債務就會像高利貸同樣越滾越多，你要麼傾家蕩產去還債（徹底重寫），還有可能 go to dead!（產品失敗）。

       聽上去很危言聳聽，可是這偏偏是我在工做生涯中屢屢看見的。當你由於技術債務積累了一年、兩年、三年時，你基於此的產品實現也會愈來愈複雜。即便你招聘到了業界大牛，當得知這種改動是顛覆性的，須要消耗大量的時間和人力時，也每每使其沒法下手。反過來我也經歷過幾回發現這種問題時，咱們據理力爭，投入階段性的力量全力還債的場景，我記憶中的幾回通宵就是在那個期間發生的。

       因此謹以一個技術人勸你們：前期若是能預見到技術債務，並且時間又緊張的話，本身多努力再努力去解決，由於這是爲你之後爭取時間和精力；中期若是能及時發現技術債務，無論付出再大也要有勇氣決然解決，由於這可能關係到產品和你的生存；後期發現了這些問題那你就吸收教訓，開展下一個項目時去避免。

      再以一個處 女座的工程師勸你們：請把本身寫代碼、作產品看成是在打磨一件藝術品，質量好壞是能夠迭代的，可是若是你沒這個態度我想永遠不會產出優秀的做品。