建站
咨詢
售后
建站咨詢
新聞中心
在遠古的時候，人們對世界的認(rèn)知有限，以為天圓地方，世界是平的。后來，隨著科技進步，大家都知道了地球的形狀，它不但不平，還有山川河流，沙漠海洋。
成都創(chuàng)新互聯(lián)是專業(yè)的原陽網(wǎng)站建設(shè)公司，原陽接單;提供成都網(wǎng)站設(shè)計、成都網(wǎng)站制作,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進行原陽網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!
這很大程度上說明了人所處的環(huán)境對認(rèn)知帶來的影響，我們看待一件事物，從不同的視角去看，所得到的結(jié)論未必是相同的。
前后端協(xié)作的研發(fā)模式
上個月有一天很奇妙，早上有個之前部門的同事跟我探討研發(fā)模式，下午有個之前同事跟我吐槽前后端溝通成本高，晚上部門群里又有人提到視圖跟服務(wù)的關(guān)系，這么多巧合，值得在這個事情上寫點東西。
回頭看看這幾年，前端領(lǐng)域在搞的一些東西，除去具體的框架和組件庫，大致有這么些：
- 工程體系：構(gòu)建、發(fā)布、持續(xù)集成、容器管理
- NodeJS實現(xiàn)的框架、中間件、服務(wù)
- 圍繞前后端協(xié)作展開的一系列探索：BaaS、BFF、函數(shù)計算、GraphQL等
- 跨端實踐
這里面，有很大一部分話題是跟廣義的“前后端分離”有關(guān)的。站在今天這個時間回頭看，看得到每個方向的進展，人們逐步習(xí)慣了前端有類型、有構(gòu)建、有包管理、有測試、有持續(xù)集成等等，前端開發(fā)逐步成為了相對嚴(yán)謹(jǐn)?shù)能浖a(chǎn)活動。
另外一方面，當(dāng)我們把目光投向整個系統(tǒng)的時候，我們也可能發(fā)現(xiàn)研發(fā)流程的一些狀況?，F(xiàn)在，一個典型的系統(tǒng)，它的開發(fā)過程可能是這樣的：
- 前端獨立系統(tǒng)
- 后端獨立系統(tǒng)
- 中間有類似 swagger 的接口約定機制
前端有一套東西，完整的組件化、構(gòu)建、發(fā)布、依賴管理，后端也有一套，但是，兩者的結(jié)合往往是很松散的，整個鏈路很長，在流程上會有很不協(xié)調(diào)的感覺。
形成這個問題的原因是整個研發(fā)過程兩極分化，斷裂得很厲害，前后端的唯一橋梁是接口，并且，一般來說，當(dāng)一端產(chǎn)生了變更之后，很難有一種自動同步機制去影響另一端，通常只能去掃描發(fā)現(xiàn)這些不一致的地方，并且手工做調(diào)整。
整個系統(tǒng)的研發(fā)流程好比細胞的增殖過程，拉伸成了兩塊，中間的維系很脆弱。
從架構(gòu)治理角度看，“兩頭大”的情況是需要去控制的，只有主從結(jié)構(gòu)的形態(tài)，在流程上才是簡單的。對這么一個問題，業(yè)界存在不同的探索途徑：
- 前端主導(dǎo)的流程
- 前后端合一的研發(fā)模式
- 后端主導(dǎo)的流程
前端主導(dǎo)的流程
前端主導(dǎo)的流程是怎樣的呢?
這個流程的要點是讓后端退化為配置，借助 BaaS，F(xiàn)aaS 這樣的基礎(chǔ)架構(gòu)，舍棄后端的構(gòu)建與發(fā)布環(huán)節(jié)，工程上就會成為這樣的形態(tài)：
這樣，后端成為了一種流程無感的環(huán)節(jié)，前端是整個項目的集成方，后端成為了一種配置化的東西，成為了前端體系下的附屬。這種模式是否能行得通，最大的先決條件就是后端接口是否穩(wěn)定。在互聯(lián)網(wǎng)企業(yè)中，尤其是領(lǐng)域模型關(guān)聯(lián)關(guān)系較少的情況下，有不少系統(tǒng)在往這個方向走。
- 輕量業(yè)務(wù)：完全 BaaS
- 較重的業(yè)務(wù)：通過 Faas 調(diào)用微服務(wù)
前后端融合的模式
另外，業(yè)界也存在一些探索，希望把前后端的開發(fā)過程融合。我們所要解決的問題一直都是變更的同步，那么，如果一個項目的前后端都位于一個工程中，天然對同步也是有利的。
這種模式下，實際上是通過兩者合一的方式，縮短了前后端研發(fā)過程之間的距離和溝通成本，在此基礎(chǔ)上，還可以有另外一些手段作優(yōu)化，比如：
- 根據(jù)后端的服務(wù)生成前端的調(diào)用接口，并且附帶 TypeScript 類型描述
- 根據(jù)后端的單元測試生成前端的 mock 數(shù)據(jù)
前后端合一的工程中，最大優(yōu)勢就是后端接口的變更一定會自動傳導(dǎo)到前端，服務(wù)接口字段變更會導(dǎo)致：
- 前端類型校驗出錯
- 前端的單元測試出錯
并且，由于二者合并在一個項目中，改了一邊忘記改另一邊的情況也更不容易發(fā)生，兩者的發(fā)布也是在同一個流程中。
這種模式普適性相對好，但是對人員全棧技能的需求是要稍高的。
后端主導(dǎo)的流程
后端主導(dǎo)的流程又是怎樣的呢?
這個流程是反過來，盡可能地把視圖弱化，讓它成為后端模型的附屬物。在很長的時間里，這種形態(tài)一直是主流，只是可能具體形式上歷經(jīng)了一些演變。
后端主導(dǎo)的流程推行到極致，工程上就會成為這樣的形態(tài)：
在這種路徑下，視圖成為了領(lǐng)域模型的附屬物，當(dāng)領(lǐng)域模型產(chǎn)生變動的時候，視圖自然跟著變動，即使是視圖之間的聯(lián)動關(guān)系，也是經(jīng)由領(lǐng)域模型之間的關(guān)系控制的。
這樣，前端成為了一種流程無感的環(huán)節(jié)，后端是整個項目的集成方，前端成為了一種配置化的東西。這條路徑的先決條件是前端的模式相對固定，可窮舉，不會存在太多的個性化交互。通常，會有一些企業(yè)軟件的研發(fā)過程采用這種模式。這種模式對人的需求是領(lǐng)域建模能力較強。
組件化
研發(fā)流程也會導(dǎo)致實施過程中的一些細節(jié)差異，比較典型的就是組件化。
組件化是一個很久遠的名詞了，自從工業(yè)革命開始，標(biāo)準(zhǔn)化的可替換部件逐步成為了生產(chǎn)效率的基石。在前端領(lǐng)域，這個詞最近也在越來越多地被提到。然而，對這個詞如何理解，不同的人有不同看法。
組件化的實施路徑是需要隨著技術(shù)方案的不同而調(diào)整的。剛才我們提到了三種研發(fā)模式，組件化實施方案也會有不同的模式。
- 前端不分層的組件化體系
- 前端分層的組件化體系
- 端到端組件化體系
前端不分層的組件化體系
這個體系是當(dāng)前前端最熟悉的路徑了，在實現(xiàn)者眼里，后端退化為接口，不關(guān)心數(shù)據(jù)之間的關(guān)系。
前端分層的組件化體系
另外存在一種實踐，在前端又引入分層，把真正的視圖和邏輯、數(shù)據(jù)等等隔離，這個時候，視圖部分實際上就可以變得非常薄，整個視圖部分的組件化，實際上類似于模板化。
端到端的組件化體系
如果考慮到實施的原則盡量簡單，端到端組件是最容易理解，集成難度最低的一種形態(tài)。
在此模式下，單個組件應(yīng)當(dāng)包含視圖到服務(wù)端模型的整個鏈路。組件只跟某個具體的領(lǐng)域模型交互，并不關(guān)心其他組件的存在。單個或者多個組件，都能夠直接運行。頁面成為一種通用的容器，把它們集成起來。
舉例來說，一個人員列表與詳情的頁面，如果實現(xiàn)為兩個組件，其功能分別如下：
- 列表組件
- 綁定了某個條件的人員列表查詢服務(wù)
- 詳情組件
- 綁定了某個具體的人員
這兩個組件應(yīng)當(dāng)是互相獨立的，在這種情況下頁面對它們的集成，包括兩者之間的聯(lián)動關(guān)系，都是在領(lǐng)域模型(后端)上定義的，然后借助特定的機制，自動就形成了聯(lián)動關(guān)系。
從實現(xiàn)角度，這種組件內(nèi)部也可能接近于其他形態(tài)的組件實現(xiàn)方式，比如，組件內(nèi)部可以有分層，當(dāng)某組件被注冊的時候，它所屬的各層是分別注冊的。
需要注意的是，以上三種實踐并非直接對應(yīng)于第一部分我們提到的三種模式，它們是存在并存關(guān)系的，可以根據(jù)業(yè)務(wù)場景去適當(dāng)進行混合。
小結(jié)
不考慮實際情況的技術(shù)選型是非?？膳碌?，并不存在通吃一切的技術(shù)方案，每種方案都有它的邊界。在實踐過程中，可以問問自己，我們正在做的這個系統(tǒng)：
- 前端跟后端，哪塊更模式化?
- 與其他系統(tǒng)的集成方式是怎樣的?
- 視圖變更與復(fù)用程度如何?
- 人員的技能狀況如何?
- 視圖是“寫”出來的，還是“配置”出來的?
對這些問題的不同回答，都會影響到具體實施路徑的選擇。
幾年前，左耳朵耗子說了一句話，被很多人圍攻：“CSS不就是配置文件么?”從前端角度看，這句話簡直大逆不道。但是，在某些場景下，當(dāng)我們把視野放在全局，到整個系統(tǒng)層面，CSS確實就可以被認(rèn)為是一種配置文件。不但如此，在有些場景下，連視圖的大部分都能算是配置文件了。
有的時候，我們也會看到一些探索，比如說，嘗試用可視化的方式去配置視圖層，在這種情況下，視圖確實就是由：
- “寫”出來的基礎(chǔ)組件
- “拼”出來的大塊模板
這兩類部分所組成的，這也是我個人在很多情況下很傾向于“模板型”視圖層框架的原因。
我們繞了很大一圈，離題萬里，那么，世界是平的嗎?
可以試試閉著眼睛去摸一下立體的地球儀，感覺是怎樣的?但實際上這是一種錯覺，因為地球儀對比例進行了夸張，以青藏高原的海拔，相對地球半徑而言，其高度差簡直可以忽略不計。所以，宏觀角度看，世界確實就是平的。
橫看成嶺側(cè)成峰，遠近高低各不同。不識廬山真面目，只緣身在此山中。
——蘇軾
后記：本文是2019年1月19日在網(wǎng)易前端技術(shù)大會上的分享。整篇文章想要解決的問題是給出一些建議：前端技術(shù)選型應(yīng)當(dāng)結(jié)合業(yè)務(wù)場景，社區(qū)方案只是自己的工具，技術(shù)人員不應(yīng)當(dāng)變成工具的奴隸。在不合適的場景下，即使是很著名、流行的工具，也應(yīng)當(dāng)果斷舍棄。
分享過程中，我提到自己給自己打的標(biāo)簽是缺乏情懷的工業(yè)黨，所謂工業(yè)黨，在我看來，有另外一個名詞可以對等，那就是生產(chǎn)力至上。一個生產(chǎn)力至上者的態(tài)度是這樣的：竭盡全力尋找出限制生產(chǎn)力發(fā)展的因素，找到最適合的生產(chǎn)方式：
- 如果生產(chǎn)工具(技術(shù)框架)是瓶頸，那就改造生產(chǎn)工具;
- 如果研發(fā)流程是瓶頸，那就重塑研發(fā)流程;
- 如果人是瓶頸，那就改變?nèi)恕?/li>
毛主席教導(dǎo)我們：“敢教日月?lián)Q新天?！?/p>
當(dāng)前題目：世界是平的嗎？——從不同角度看前端
瀏覽路徑：http://www.5511xx.com/article/dpihpch.html
