摘要:最近一段時間,經常看到技術債務相關文章,最近也是參與了技術債務的清理。但是本文的背景是在一些大型的前端項目中技術債務的產生隨著前端復雜度的增加,技術債務就開始慢慢的在浮現出來。
最近一段時間,經常看到技術債務相關文章,最近也是參與了技術債務的清理。所以從參與者的角度介紹下遇到債務問題和對于技術債務的理解
其實在于前端領域,技術債務的相對較少,因為前端有一個特點就是隨著功能和設計的升級,相對容易重構。
但是本文的背景是在一些大型的前端項目中
技術債務的產生隨著前端復雜度的增加,技術債務就開始慢慢的在浮現出來。特別是系統級別的單頁面應用,功能不斷的疊加,技術不斷的更新,架構不斷的升級,技術債務就暴露出來了。
舉一個例子(如有雷同,表示慰問):
最開始嘗試mvc時,使用了backbone開發單頁面,然后一年后,發現angularjs特別火,而且調研發現這種mvvm模式更加提高效率,這時項目中一些新的模塊開始都用上了angularjs,然后隨著時間的推移,發現angularjs存在性能瓶頸,這時發現reactjs的虛擬dom和單向數據流很好,然后繼續在新模塊中引入。然后某一天,回頭一看。。。WTF。。。發現架構混亂,維護困難,新業務開展困難等等。。。
如上面的例子,架構的升級,新技術的引入,特別容易引發技術債務的出現。
正如我之前的文章《如何在大公司成長》提到的,在成熟的系統中引入新技術其實是一個挑戰非常大的事情,因為首先你必須控制好技術債務。
因為在厲害的架構師也無法設計一個面向未來可以一直不變的框架,再流行的模式也會不斷演變。如果解決不好新舊的過度就很容易出現上面的情況。
可以直白的說,在越復雜的系統上面開發,就是帶著越重的腳鐐在跳舞。
技術債務的定義再舉一個例子,也是引發技術債務的一種情況:
由于進度的原因,不得不使用一些hack的方式(而不是從根源解決)去完成任務,然后在沒有來得及刪掉這種hack方式前,有其他人在你的基礎上繼續迭代和模仿,最后變得想去掉這種hack方式都去不掉。
什么樣的問題稱之為技術債務,我和網上觀點有些不同。對于一些編程習慣,編碼方式,有異味的代碼等等,我認為這些應該屬于代碼素養的范疇,這些可以不斷改善,而且完全可以小范圍的重構解決,不會形成疊加效應。
我理解的技術債務是它的存在影響了整個系統的效率和阻礙了系統的發展,隨著系統復雜度的增加,問題會不斷的被放大。
下面一一說明,并且配合舉例
影響日常的開發效率
我認為這個應該屬于最嚴重的影響,由于債務的原因,嚴重拖慢了開發效率,導致開發人員開法困難。
舉例:
兩個模塊共用一個修改組件,由于兩個模塊底層依賴不一樣,導致需要重復開發兩次。而且每一次需求升級,都是兩次的重復開發。這種情況的結果直接導致人力成倍翻倍。
提高了開發人員的學習成本
這也是對于工程效率的影響,由于技術債務的積累,導致開發人員需要花更多的時間去理解開發任務,需要更多的時間學習理解。
舉例
由于歷史原因,同樣一個組件/模塊有兩種實現方式,新同學在選擇時第一感覺就是迷茫,亂,煩躁,不知所措,還需要花人力去了解哪個更加合適,哪個會有什么樣的坑等等,如果選擇錯誤了,還需要花無謂的時間重做。
持續的影響網站性能
債務的積累必定是一些遺留問題,特點就是隨著時間,會越來越多,越來越復雜,越來越不敢砍掉。直接導致的問題就是,遺留代碼太多,這些代碼都是對線程的無謂消耗。最后的結果就是網站越來越慢
舉例
控件最初使用的是1.0版本,換2.0時,由于舊的業務沒有隨著升級,就導致系統里面ui庫多版本,這樣,ui初始化就需要初始化兩份,而且合并打包的時候,代碼也會多出很多。
容易觸發bug
舊代碼的錯誤使用,或者使用不當,經常會導致一些莫名其妙的bug,而且極其難定位。
舉例
在開發中不小心使用了舊代碼的一些功能,而其他人員在清理或者修改重構時沒有考慮,直接就會間接的產生bug。也是因為這種原因,舊代碼也越來越不敢清理
成為了業務規劃的瓶頸
由于一些架構因素,導致某些業務功能無法實現,或者實現起來的成本特別高。
如何避免技術債務舉例
兩個模塊由于底層的技術架構不同,如果pm希望模塊間有一些數據的互通,或者功能的互相調用,這種需求就是受到技術的限制而實現不了(當然可以通過一些hack或者非常規方式實現,但是每一次hack都是一次新債務的產生)
技術債務能避免嗎?
我覺得不可能,因為隨著復雜度的增長,債務也在慢慢增長,只是快和慢的問題,也許你今天寫的一個完美的功能,一年以后,對于新的架構就是一個債務,因為技術在不斷再更新換代,沒有任何一種模式是銀彈。
如果非要有一種辦法避免,我能想到的就拒絕新技術引入,一種模式堅持到底,但這肯定是不實際。
所以個人覺得對于技術債務
我們首先我們需要認識到債務的存在,最好有一個債務管理機制。例如有一個債務范圍的控制,當影響面達到一定程度,就必須去清理。
其次認識到清理債務對當下的收益可能不明顯,但是收益在未來會不斷放大,所以對于債務的清理,我們必須要去面對,而不是逃避。
最后,還需要在平時的開發中,有技術債務的意識,例如,臨時方案真的是臨時的嗎?開發出來的代碼可維護嗎?
http://tangguangyao.github.io/
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/86143.html
摘要:什么是技術債務由于團隊在開始新項目的時候,舊項目的任何未完成的事情都會形成技術債務。技術債務產生原因有哪些原因技術債務的產生原因是多方面的,其形成的過程和生活中所擔的債務形成的過程具有非常大的相似性。 什么是技術債務? 由于團隊在開始新項目的時候,舊項目的任何未完成的事情都會形成技術債務。比如代碼不規范,需要進行代碼重構的重構債務;比如設計上未完成的設計債務,等等,統歸于技術債務。 而...
摘要:什么是技術債務由于團隊在開始新項目的時候,舊項目的任何未完成的事情都會形成技術債務。技術債務產生原因有哪些原因技術債務的產生原因是多方面的,其形成的過程和生活中所擔的債務形成的過程具有非常大的相似性。 什么是技術債務? 由于團隊在開始新項目的時候,舊項目的任何未完成的事情都會形成技術債務。比如代碼不規范,需要進行代碼重構的重構債務;比如設計上未完成的設計債務,等等,統歸于技術債務。 而...
閱讀 5289·2021-09-22 15:59
閱讀 1868·2021-08-23 09:42
閱讀 2570·2019-08-29 18:42
閱讀 3454·2019-08-29 10:55
閱讀 2067·2019-08-27 10:57
閱讀 1764·2019-08-26 18:27
閱讀 2730·2019-08-23 18:26
閱讀 2927·2019-08-23 14:40