1. 程式人生 > >Vue2.0中,“漸進式框架”和“自底向上增量開發的設計”是什麼

Vue2.0中,“漸進式框架”和“自底向上增量開發的設計”是什麼

在我看來,漸進式代表的含義是:主張最少。

每個框架都不可避免會有自己的一些特點,從而會對使用者有一定的要求,這些要求就是主張,主張有強有弱,它的強勢程度會影響在業務開發中的使用方式。

比如說,Angular,它兩個版本都是強主張的,如果你用它,必須接受以下東西:

- 必須使用它的模組機制
- 必須使用它的依賴注入
- 必須使用它的特殊形式定義元件(這一點每個檢視框架都有,難以避免)

所以Angular是帶有比較強的排它性的,如果你的應用不是從頭開始,而是要不斷考慮是否跟其他東西整合,這些主張會帶來一些困擾。

比如React,它也有一定程度的主張,它的主張主要是函數語言程式設計的理念,比如說,你需要知道什麼是副作用,什麼是純函式,如何隔離副作用。它的侵入性看似沒有Angular那麼強,主要因為它是軟性侵入。

你當然可以只用React的檢視層,但幾乎沒有人這麼用,為什麼呢,因為你用了它,就會覺得其他東西都很彆扭,於是你要引入Flux,Redux,Mobx之中的一個,於是你除了Redux,還要看saga,於是你要糾結業務開發過程中每個東西有沒有副作用,純不純,甚至你連這個都可能不能忍:

const getData = () => {
// 如果不存在,就在快取中建立一個並返回
// 如果存在,就從快取中拿
}

因為你要糾結它有外部依賴,同樣是不加引數呼叫,連續兩次的結果是不一樣的,於是不純。

為什麼我一直不認同在中後臺專案中使用React,原因就在這裡,我反對的是整個業務應用的函式式傾向,很多人都是看到有很多好用的React元件,就會傾向於把它引入,然後,你知道怎麼把自己的業務對映到函式式的那套理念上嗎?

函數語言程式設計,無副作用,寫出來的程式碼沒有bug,這是真理沒錯,但是有兩個問題需要考慮:

1. JS本身,有太多特性與純函式式的主張不適配,這一點,題葉能說得更多
2. 業務系統裡面的實體關係,如何組織業務邏輯,幾十年來積累了無數的基於設計模式的場景經驗,有太多的東西可以模仿,但是,沒有人給你總結那麼多如何把你的厚重業務對映到函式式理念的經驗,這個地方很考驗綜合水平的,真的每個人都有能力去做這種對映嗎?

函數語言程式設計無bug的根本就在於要把業務邏輯完全都依照這套理念搞好,你看看自己公司做中後臺的員工,他們熟悉的是什麼?是基於傳統OO設計模式的這套東西,他們以為拿著你們給的元件庫就得到了一切,但是可能還要被灌輸函數語言程式設計的一整套東西,而且又沒人告訴他們在業務場景下,如何規劃業務模型、組織程式碼,還要求快速開發,怎麼能快起來?

所以我真是心疼這些人,他們要的只是元件庫,卻不得不把業務邏輯的思考方式也作轉換,這個事情沒有一兩年時間洗腦,根本洗不到能開發業務的程度。

沒有好元件庫的時候,大家痛點在檢視層,有了基於React的元件化,把原先沒那麼痛的業務邏輯部分搞得也痛起來了,原先大家按照設計模式教的東西,照貓畫虎還能繼續開發了,學了一套新理念之後,都不知道怎麼寫程式碼了,怎麼寫都懷疑自己不對,可怕。

我寧可支援Angular也不支援React的原因也就在此,Angular至少在業務邏輯這塊沒有軟主張,能夠跟OO設計模式那套東西配合得很好。我面對過很多商務場景,都是前端很厚重的東西,不僅僅是管理控制檯這種,這類東西里面,業務邏輯的佔比要比檢視大挺多的,如何組織這些東西,目前幾個主流技術棧都沒有解決方案,要靠業務架構師去擺平。

如果你的場景不是這麼厚重的,只是簡單管理控制檯,那當我沒說好了。

框架是不能解決業務問題的,只能作為工具,放在合適的人手裡,合適的場景下。

現在我要說說為什麼我這麼支援Vue了,沒什麼,可能有些方面是不如React,不如Angular,但它是漸進的,沒有強主張,你可以在原有大系統的上面,把一兩個元件改用它實現,當jQuery用;也可以整個用它全家桶開發,當Angular用;還可以用它的檢視,搭配你自己設計的整個下層用。你可以在底層資料邏輯的地方用OO和設計模式的那套理念,也可以函式式,都可以,它只是個輕量檢視而已,只做了自己該做的事,沒有做不該做的事,僅此而已。

漸進式的含義,我的理解是:沒有多做職責之外的事。

相關推薦

no