最近一段時間,常常看到技術債務相關文章,最近也是參與了技術債務的清理。因此從參與者的角度介紹下遇到債務問題和對於技術債務的理解 前端
其實在於前端領域,技術債務的相對較少,由於前端有一個特色就是隨着功能和設計的升級,相對容易重構。 react
可是本文的背景是在一些大型的前端項目中git
隨着前端複雜度的增長,技術債務就開始慢慢的在浮現出來。特別是系統級別的單頁面應用,功能不斷的疊加,技術不斷的更新,架構不斷的升級,技術債務就暴露出來了。angularjs
舉一個例子(若有雷同,表示慰問):
最開始嘗試mvc時,使用了backbone開發單頁面,而後一年後,發現angularjs特別火,並且調研發現這種mvvm模式更加提升效率,這時項目中一些新的模塊開始都用上了angularjs,而後隨着時間的推移,發現angularjs存在性能瓶頸,這時發現reactjs的虛擬dom和單向數據流很好,而後繼續在新模塊中引入。而後某一天,回頭一看。。。WTF。。。發現架構混亂,維護困難,新業務開展困難等等。。。github
如上面的例子,架構的升級,新技術的引入,特別容易引起技術債務的出現。
正如我以前的文章《如何在大公司成長》提到的,在成熟的系統中引入新技術實際上是一個挑戰很是大的事情,由於首先你必須控制好技術債務。
由於在厲害的架構師也沒法設計一個面向將來能夠一直不變的框架,再流行的模式也會不斷演變。若是解決很差新舊的過分就很容易出現上面的狀況。 編程
能夠直白的說,在越複雜的系統上面開發,就是帶着越重的腳鐐在跳舞。微信
再舉一個例子,也是引起技術債務的一種狀況:
因爲進度的緣由,不得不使用一些hack的方式(而不是從根源解決)去完成任務,而後在沒有來得及刪掉這種hack方式前,有其餘人在你的基礎上繼續迭代和模仿,最後變得想去掉這種hack方式都去不掉。架構
什麼樣的問題稱之爲技術債務,我和網上觀點有些不一樣。對於一些編程習慣,編碼方式,有異味的代碼等等,我認爲這些應該屬於代碼素養的範疇,這些能夠不斷改善,並且徹底能夠小範圍的重構解決,不會造成疊加效應。
我理解的技術債務是它的存在影響了整個系統的效率和阻礙了系統的發展,隨着系統複雜度的增長,問題會不斷的被放大。
下面一一說明,而且配合舉例mvc
影響平常的開發效率
我認爲這個應該屬於最嚴重的影響,因爲債務的緣由,嚴重拖慢了開發效率,致使開發人員開法困難。框架
舉例:
兩個模塊共用一個修改組件,因爲兩個模塊底層依賴不同,致使須要重複開發兩次。並且每一次需求升級,都是兩次的重複開發。這種狀況的結果直接致使人力成倍翻倍。
提升了開發人員的學習成本
這也是對於工程效率的影響,因爲技術債務的積累,致使開發人員須要花更多的時間去理解開發任務,須要更多的時間學習理解。
舉例
因爲歷史緣由,一樣一個組件/模塊有兩種實現方式,新同窗在選擇時第一感受就是迷茫,亂,煩躁,不知所措,還須要花人力去了解哪一個更加合適,哪一個會有什麼樣的坑等等,若是選擇錯誤了,還須要花無謂的時間重作。
持續的影響網站性能
債務的積累一定是一些遺留問題,特色就是隨着時間,會愈來愈多,愈來愈複雜,愈來愈不敢砍掉。直接致使的問題就是,遺留代碼太多,這些代碼都是對線程的無謂消耗。最後的結果就是網站愈來愈慢
舉例
控件最初使用的是1.0版本,換2.0時,因爲舊的業務沒有隨着升級,就致使系統裏面ui庫多版本,這樣,ui初始化就須要初始化兩份,並且合併打包的時候,代碼也會多出不少。
容易觸發bug
舊代碼的錯誤使用,或者使用不當,常常會致使一些莫名其妙的bug,並且極其難定位。
舉例
在開發中不當心使用了舊代碼的一些功能,而其餘人員在清理或者修改重構時沒有考慮,直接就會間接的產生bug。也是由於這種緣由,舊代碼也愈來愈不敢清理
成爲了業務規劃的瓶頸
因爲一些架構因素,致使某些業務功能沒法實現,或者實現起來的成本特別高。
舉例
兩個模塊因爲底層的技術架構不一樣,若是pm但願模塊間有一些數據的互通,或者功能的互相調用,這種需求就是受到技術的限制而實現不了(固然能夠經過一些hack或者很是規方式實現,可是每一次hack都是一次新債務的產生)
技術債務能避免嗎?
我以爲不可能,由於隨着複雜度的增加,債務也在慢慢增加,只是快和慢的問題,也許你今天寫的一個完美的功能,一年之後,對於新的架構就是一個債務,由於技術在不斷再更新換代,沒有任何一種模式是銀彈。
若是非要有一種辦法避免,我能想到的就拒絕新技術引入,一種模式堅持到底,但這確定是不實際。
因此我的以爲對於技術債務
咱們首先咱們須要認識到債務的存在,最好有一個債務管理機制。例若有一個債務範圍的控制,當影響面達到必定程度,就必須去清理。
其次認識到清理債務對當下的收益可能不明顯,可是收益在將來會不斷放大,因此對於債務的清理,咱們必需要去面對,而不是逃避。
最後,還須要在平時的開發中,有技術債務的意識,例如,臨時方案真的是臨時的嗎?開發出來的代碼可維護嗎?