關(guān)于前端的技術(shù)債務(wù)

546669204 發(fā)布于2019-08-21 10:45 / 2196人閱讀

摘要：最近一段時間，經(jīng)常看到技術(shù)債務(wù)相關(guān)文章，最近也是參與了技術(shù)債務(wù)的清理。但是本文的背景是在一些大型的前端項目中技術(shù)債務(wù)的產(chǎn)生隨著前端復(fù)雜度的增加，技術(shù)債務(wù)就開始慢慢的在浮現(xiàn)出來。

最近一段時間，經(jīng)常看到技術(shù)債務(wù)相關(guān)文章，最近也是參與了技術(shù)債務(wù)的清理。所以從參與者的角度介紹下遇到債務(wù)問題和對于技術(shù)債務(wù)的理解

其實在于前端領(lǐng)域，技術(shù)債務(wù)的相對較少，因為前端有一個特點就是隨著功能和設(shè)計的升級，相對容易重構(gòu)。

但是本文的背景是在一些大型的前端項目中

技術(shù)債務(wù)的產(chǎn)生

隨著前端復(fù)雜度的增加，技術(shù)債務(wù)就開始慢慢的在浮現(xiàn)出來。特別是系統(tǒng)級別的單頁面應(yīng)用，功能不斷的疊加，技術(shù)不斷的更新，架構(gòu)不斷的升級，技術(shù)債務(wù)就暴露出來了。

舉一個例子（如有雷同，表示慰問）：   
最開始嘗試mvc時，使用了backbone開發(fā)單頁面，然后一年后，發(fā)現(xiàn)angularjs特別火，而且調(diào)研發(fā)現(xiàn)這種mvvm模式更加提高效率，這時項目中一些新的模塊開始都用上了angularjs，然后隨著時間的推移，發(fā)現(xiàn)angularjs存在性能瓶頸，這時發(fā)現(xiàn)reactjs的虛擬dom和單向數(shù)據(jù)流很好，然后繼續(xù)在新模塊中引入。然后某一天，回頭一看。。。WTF。。。發(fā)現(xiàn)架構(gòu)混亂，維護困難，新業(yè)務(wù)開展困難等等。。。

如上面的例子，架構(gòu)的升級，新技術(shù)的引入，特別容易引發(fā)技術(shù)債務(wù)的出現(xiàn)。
正如我之前的文章《如何在大公司成長》提到的，在成熟的系統(tǒng)中引入新技術(shù)其實是一個挑戰(zhàn)非常大的事情，因為首先你必須控制好技術(shù)債務(wù)。
因為在厲害的架構(gòu)師也無法設(shè)計一個面向未來可以一直不變的框架，再流行的模式也會不斷演變。如果解決不好新舊的過度就很容易出現(xiàn)上面的情況。

可以直白的說，在越復(fù)雜的系統(tǒng)上面開發(fā)，就是帶著越重的腳鐐在跳舞。

再舉一個例子，也是引發(fā)技術(shù)債務(wù)的一種情況：  
由于進度的原因，不得不使用一些hack的方式（而不是從根源解決)去完成任務(wù)，然后在沒有來得及刪掉這種hack方式前，有其他人在你的基礎(chǔ)上繼續(xù)迭代和模仿，最后變得想去掉這種hack方式都去不掉。

技術(shù)債務(wù)的定義

什么樣的問題稱之為技術(shù)債務(wù)，我和網(wǎng)上觀點有些不同。對于一些編程習慣，編碼方式，有異味的代碼等等，我認為這些應(yīng)該屬于代碼素養(yǎng)的范疇，這些可以不斷改善，而且完全可以小范圍的重構(gòu)解決，不會形成疊加效應(yīng)。
我理解的技術(shù)債務(wù)是它的存在影響了整個系統(tǒng)的效率和阻礙了系統(tǒng)的發(fā)展，隨著系統(tǒng)復(fù)雜度的增加，問題會不斷的被放大。
下面一一說明，并且配合舉例

技術(shù)債務(wù)的影響

影響日常的開發(fā)效率
我認為這個應(yīng)該屬于最嚴重的影響，由于債務(wù)的原因，嚴重拖慢了開發(fā)效率，導(dǎo)致開發(fā)人員開法困難。

舉例：   
兩個模塊共用一個修改組件，由于兩個模塊底層依賴不一樣，導(dǎo)致需要重復(fù)開發(fā)兩次。而且每一次需求升級，都是兩次的重復(fù)開發(fā)。這種情況的結(jié)果直接導(dǎo)致人力成倍翻倍。

提高了開發(fā)人員的學(xué)習成本
這也是對于工程效率的影響，由于技術(shù)債務(wù)的積累，導(dǎo)致開發(fā)人員需要花更多的時間去理解開發(fā)任務(wù)，需要更多的時間學(xué)習理解。

舉例
由于歷史原因，同樣一個組件/模塊有兩種實現(xiàn)方式，新同學(xué)在選擇時第一感覺就是迷茫，亂，煩躁，不知所措，還需要花人力去了解哪個更加合適，哪個會有什么樣的坑等等，如果選擇錯誤了，還需要花無謂的時間重做。

持續(xù)的影響網(wǎng)站性能
債務(wù)的積累必定是一些遺留問題，特點就是隨著時間，會越來越多，越來越復(fù)雜，越來越不敢砍掉。直接導(dǎo)致的問題就是，遺留代碼太多，這些代碼都是對線程的無謂消耗。最后的結(jié)果就是網(wǎng)站越來越慢

舉例  
控件最初使用的是1.0版本，換2.0時，由于舊的業(yè)務(wù)沒有隨著升級，就導(dǎo)致系統(tǒng)里面ui庫多版本，這樣，ui初始化就需要初始化兩份，而且合并打包的時候，代碼也會多出很多。

容易觸發(fā)bug
舊代碼的錯誤使用，或者使用不當，經(jīng)常會導(dǎo)致一些莫名其妙的bug，而且極其難定位。

舉例  
在開發(fā)中不小心使用了舊代碼的一些功能，而其他人員在清理或者修改重構(gòu)時沒有考慮，直接就會間接的產(chǎn)生bug。也是因為這種原因，舊代碼也越來越不敢清理

成為了業(yè)務(wù)規(guī)劃的瓶頸
由于一些架構(gòu)因素，導(dǎo)致某些業(yè)務(wù)功能無法實現(xiàn)，或者實現(xiàn)起來的成本特別高。

舉例  
兩個模塊由于底層的技術(shù)架構(gòu)不同，如果pm希望模塊間有一些數(shù)據(jù)的互通，或者功能的互相調(diào)用，這種需求就是受到技術(shù)的限制而實現(xiàn)不了（當然可以通過一些hack或者非常規(guī)方式實現(xiàn)，但是每一次hack都是一次新債務(wù)的產(chǎn)生）

如何避免技術(shù)債務(wù)

技術(shù)債務(wù)能避免嗎？
我覺得不可能，因為隨著復(fù)雜度的增長，債務(wù)也在慢慢增長，只是快和慢的問題，也許你今天寫的一個完美的功能，一年以后，對于新的架構(gòu)就是一個債務(wù)，因為技術(shù)在不斷再更新?lián)Q代，沒有任何一種模式是銀彈。
如果非要有一種辦法避免，我能想到的就拒絕新技術(shù)引入，一種模式堅持到底，但這肯定是不實際。

所以個人覺得對于技術(shù)債務(wù)
我們首先我們需要認識到債務(wù)的存在，最好有一個債務(wù)管理機制。例如有一個債務(wù)范圍的控制，當影響面達到一定程度，就必須去清理。
其次認識到清理債務(wù)對當下的收益可能不明顯，但是收益在未來會不斷放大，所以對于債務(wù)的清理，我們必須要去面對，而不是逃避。
最后，還需要在平時的開發(fā)中，有技術(shù)債務(wù)的意識，例如，臨時方案真的是臨時的嗎？開發(fā)出來的代碼可維護嗎？

微信公眾號

博客地址

http://tangguangyao.github.io/