標籤:

前端架構是什麼,前端有架構可談嗎?

在跟同事聊前端架構的時候,大家都會反問一句前端有架構嗎?大家眼裡只有後端可以談架構,那後端什麼可以稱為架構。

前端的文件組織,整體的運行機制等都只能算是工程化的一部分嗎?


後文於2016.07.20新增內容,以下是原文。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

架構是一個演變的過程。

它指的不是隨著歷史的演變,而是隨著項目演變。

通常說架構,指的是架構模式,自創的架構很少。

了解架構模式,才能心有餘力的應對項目的發展。

前端項目大概會經歷以下這些階段:

1. 整體渲染

2. 結構行為表現分離

3. 隔離邏輯單元

4. 插件

5. 模塊

6. 前端MVC/MVVM

7. 組件

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

下面分別介紹一下:

1. 整體渲染

所有頁面代碼放到了一個html文檔中,適合個人實驗室項目。

新建一個文件,快速的驗證某個功能或者開發某個組件,再移植到開發環境中。

優點:開發速度快,執行過程清晰

不足:不容易分工合作

2. 結構行為表現分離

當頁面中有了好幾個Script和Style片段,這時候就想著是不是該把它們放到一個文件中了。

不然總在一個頁面拖上拖下的改動太麻煩了。

結構:HTML

行為:JavaScript

表現:CSS

優點:關注點分離

不足:職責不明確

3. 隔離邏輯單元

一個JavaScript文件太大了,裡面包含了很多不同的邏輯功能。

還是把獨立的功能提取出來吧,這樣省的每次都在一個文件中改。

優點:面向復用

不足:功能點分散

4. 插件

開閉原則:一個軟體實體如類、模塊和函數應該對擴展開放,對修改關閉。

這讓我想起了小時候的紅白機。

這個借鑒了微內核架構的思想,整個網站由一個很小的核心構成,所有功能都是嫁接上去的。

這樣核心基本上穩定了,只剩下增量的插件開發。

優點:對需求的響應快

不足:插件難以規範化

5. 模塊

當網站有了很多種獨立的部分,微內核已經不能勝任了,因為各個插件之間產生了關聯。

就需要一個處理模塊依賴的東西出現。

於是人們定義了模塊規範,分別有自己的處理模塊依賴的辦法。

主要以下幾種模塊規範

(1)AMD規範(用戶客戶端,RequireJS實現)

(2)CommonJS規範(用於服務端,Browserify實現)

(3)EcmaScript 6 Module

6. 前端MVC/MVVM

不止後端有MVC/MVVM,同樣的思想也可以用在前端,並且人們已經實現了。

主要目的是為了處理複雜的單頁面應用,讓三個層面獨立開發,減輕腦力負擔。

View:用戶界面

Model:數據表的實體類

Controller/ViewModel:處理View和Model之間的關係

主要實現有以下幾個:

(1)Backbone

(2)Knockout

(3)AngularJS

7. 組件

組件並不是一個新興的概念,但是React.js強制組件化,所以看來才那麼新穎。

它把JavaScript,CSS,HTML重新打包,當做一個邏輯單元來看待。

有點像中國古代的「活字印刷」,不是嗎,我們祖先的智慧啊。

單一職責原則:一個類應該只有一個發生變化的原因。

組合/聚集復用原則:盡量使用合成/聚合,而不是使用繼承。

React.js

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

各種架構模式都有自己的特點,身為一個前端工程師這些都是需要了解的,

然而,更重要的是,結合項目實際,靈活運用隨機應變

各種庫豐富多彩,它們也是為了解決那個階段的問題而出現的。

(先佔位,以後慢慢豐富。。。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

以下更新自2016.07.20

這麼長時間沒有更新,是因為這一年,前端發生了天翻地覆的變化,

等一切貌似都塵埃落定,我們才能好好的回顧剛剛發生了什麼。

2015年,React潮流已經席捲了整個前端,但還不是那麼主流,

大多數公司持觀望態度,組件也不是人人都在議論的概念。

而到了2016年,隨著Angular,Vue這些新框架的出現,

隨著TC39 process的進展,以及Webpack,Babel等工具對EcmaScript新特性的支撐,

再加上Web Components規範的推廣,

該來的貌似都來了,好戲才真的開始了

到現在為止,不會用ES2015寫代碼,不懂Redux,會覺得很尷尬。

不會一些TypeScript,不懂Virtual-DOM,不了解Diff演算法,會覺得自己落伍了。

而這一切,正在慢慢變成主流,You-Dont-Need-jQuery並不是因為jQuery不好用了,

而是應用場景變複雜了,直接操作DOM的機會越來越少了,

瀏覽器兼容性雖然會一直存在,但也不是最重要的問題了。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

為了看清到底發生了什麼,我把上文提到的前端項目經歷之階段進行了擴展,

我們漸漸看到,前後端分工畢竟只是角色的分離,

所用的技術棧正在慢慢靠攏,作為一名合格的工程師越來越難了。

包括Java1.8引入的lambda,包括ES2015引入的class。

ES2015 Generator,以及Stage 1的Decorator,在Python中又是多麼的熟悉,

先進的想法並不會區分前後端,而是被用到了所有適用的地方。

一個軟體項目,隨著待解決業務問題的發展,和問題複雜度的不同,會存在以下幾個階段,

1. 具體解決方案

2. 共用代碼

3. 功能獨立的工具

4. 架構模式

5. 領域特定語言(DSL

前文提到的,

整體渲染是一種具體的解決方案,

結構行為表現分離,是為了共用代碼,

隔離邏輯單元,目的是提取出功能獨立的工具,

插件(微內核),模塊(分層?),MVC/MVVM,組件(微服務),屬於不同的軟體架構模式,

JSX,TypeScript,Elm可以看做領域特定語言。

根據具體的項目情況,項目組的的人員安排,

架構師會選出當前適用的階段,並規划出未來的發展方向。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

為什麼人們都在議論組件?

是因為組件有助於降低業務代碼的複雜度。

組件是一種可拼裝的功能集,業務代碼只需要解決拼裝問題,

通過組件的再組合,就會不斷增加細節的粒度,使業務邏輯更清晰。

React作為純凈的View層,為什麼會成功?

React率先隔離了數據流和對數據的展示兩個部分,

這不但讓數據有了不同形式的展示方式(React Native

而且還加快了數據流引擎的更新換代。

無論是事件驅動的Flux,還是基於狀態機的Redux,都是具體的不同實現。

加上響應式編程在背後的推動,View層的分離會讓事情變得更美好。

為什麼Angular會擁抱TypeScript?

使用動態弱類型的語言JavaScript,軟體規模增加會導致很多意料之外的運行時錯誤,

誠然,對軟體進行測試可以減少故障,根據哥德爾不完備性定理也離不開測試。

可是提高類型系統的安全性和可靠性,也是人們喜聞樂見的事情。

無論是Flow,還是TypeScript,都是一種嘗試(Flow vs TypeScript

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

JS高級前端開發 159758989


兩個都不懂前端的人 怎麼可能聊出前端架構。


只是切圖的話,就不需要架構了,很多回答都證明了這一點。


我就瞎說一句實話:大部分前端工程沒有架構,也不需要架構。這就像給手機貼膜一樣。等你的架構做好了,你的產品都快下線了。


首先架構是為了解決更為複雜的問題而提出的,那些說前端沒架構的人估計是沒怎麼接觸過複雜的前端項目


題中說到「前端的文件組織,整體的運行機制等都只能算是工程化的一部分嗎?」

既然會這麼想,說明你們的項目就是這麼設計的。當然,大多數項目都是這麼設計的。

那究竟「有沒有其他的設計方案,其他的文件組織方案和整體運行機制?」

當然是有的。前後端「分離」唄。

前端是什麼?

從文件角度來講,前端是html+css+js。跟後端有關係嗎?

從產品角度來講,前端是展現給用戶看和操作的界面,跟後端有關係嗎?

跟後端有關係嗎?

A 有啊,html要寫成模板啊,要寫jsp,php,ejs,twig,swig,jade,smarty呀,

B 有啊,要有入口啊,要有路由啊

C 有啊,要動態數據啊

以上這些是前後端分離的阻礙嗎?

(晚上答題好無聊)

不是。

browser端模板引擎多的是,比如上面的swig。高級一點的組件引擎也多的是,比如angular2,react,vuejs。

入口和路由?angular router, routerjs 什麼的也多的是。

這裡插一句,之前某些前後端解耦架構設計里用nodejs做前端路由的方案和這裡說的瀏覽器端的路由是不一樣的。

動態數據。這個其實有的談,但是這裡的回答就是前後端的數據通信。

(晚上答題好無聊)

曬個文件結構圖結尾。


首先後端可以有架構。

然後前端可以比後端複雜。我廠三年來前端單頁面應用各種提需求改需求增加統計招新人重構組件等等,代碼量達到壓縮後 2M,純粹我們寫的單個頁面代碼壓縮後 2M。除了頻繁的改動還需要努力優化性能。

考慮到 JavaScript 大多數都是腳本語言,代數類型系統,不可變數據,IDE 這之類的黑科技很多用不上,拿什麼保證程序的可靠性呢?

前端都已經比後端複雜了,MVC 抽象也走得比後端 MVC 更遠。這種場景下抽象的模式,組件之間劃分和通訊的設計變得重要而且迫切,出現架構不奇怪。


架構。。架你妹啊,天天整些看起來高端的詞有毛線用,還不如老實去寫幾行代碼


私以為自從node出現前端就已經到處是架構了……

反而是架構太多有些蛋疼……

還好我不是前端


先不提前端有沒有架構,我只就題主的這句話來談談我對前端、對軟體工程的看法:「在跟同事聊前端架構的時候,大家都會反問一句前端有架構嗎?」

本人前端開發三年,境界有限,歡迎大神指點。

這句話,說得好聽點,是對前端的誤解,說得難聽點是對前端的歧視(前面的答案里仍有人,所謂的「後端」,在說這樣的話)。就像眾所周知的一直以來存在的歧視鏈:

c&>c++&>java&>php&>前端。

前端本質上屬於客戶端,就跟拿Java做Android,拿Object-C/Swift做iOS,拿C++/C#做windows開發一樣。而區別如下圖:

很多人認為前端無架構,而不會覺得客戶端無架構,說到底是因為客戶端更"底層"。就像c比php更底層一樣。我看了"很多"計算機原理的書、學了"很多"底層知識,才有現在的能力,你們做前端的不費什麼力氣,寫個html/css,拿js做做特效,也敢談架構?too young。(我把"很多"打了引號,是因為根據個人經驗,有這樣想法的人,其實了解的並不多,真正的大牛往往謙虛,所謂半瓶子水晃得厲害)

到這裡,提到的都是底層知識,卻忽略了業務,而絕大部分的程序員都是在做業務,而不是開發操作系統、設計Web Server,發明編程語言。當業務達到一定規模,為了解決由此帶來的複雜性,前端自然就需要談及架構。況且現在前端承擔的職責也越來越多,不再是多年前純布局,做做表單校驗。

而拋開業務,客戶端/Server端一樣沒有架構可言,做前端也可以拿php/java/python不費力氣的搭建一個個人博客站點,就跟做Server的可以很容易找幾個jQuery插件做個有特效的靜態頁面,然後說一句:前端就這麼回事,一樣。

話說回來,由於客戶端/Server端更底層,複雜度更大,職責也更多。這也是前端的天花板所在。但很多人,就他們對系統的理解,還遠遠沒觸到天花板,不管是前端or後端。就算他們多了解了一點底層知識,也派不上太多用場。

至於到底什麼是架構,可以去google搜,專業描述一大堆,就怕看不懂。在我看來,別糾結什麼是架構,而多思考眼下的問題,思考解決問題的能力。架構也好、設計模式也好、各種框架、工程化方案、編程語言也好,都是為解決問題而存在。什麼階段解決什麼問題。跟一個不斷壯大的產品,問題來了,解決了,也就成長了。


理想情況下,

web1.0和web3.0的前端是非常重的。

對於web1.0,甚至幾乎完全可以前端化。


架構感覺就是讓東西更有條理吧,後端有,前端有,創業有,說個不靠譜點的,做人應該也有架構的吧。。


只要前端是 thick client (fat client) 就有架構可談,即使只做 presentation 也須 handle multiple views.


是整個web頁面開發,調試,生產狀態的規範流程

@何幻 的答案很清晰了,我補充一點,就是調試,糾錯與生產部署。

前端是有很多工具幫助調試的,例如 karma Karma - Spectacular Test Runner for Javascript

還有包管理工具,bower,幫你解決複雜的依賴關係

自動化工具grunt,資源的壓縮,整合,產出可部署內容等


架構和框架都分不清的就不要來回答了好嗎...


架構你妹啊,整天架構這個架構那個,整天MV這個MV那個,怎麼不自己拍個MV去啊。

最近想招個架構師,簡歷寫的天花亂墜,問了三句不到直接滾蛋,全是面向百度編程啊!

先把基本功練好了行不,就知道點皮毛,再整個拍MV的庫,就好意思說自己搞架構的?


科科,現在前端遇到的問題是架構太多不知道選哪個更合適。


如果項目很大了,當然是有架構咯。


什麼代碼都需要架構,只要是代碼,只是架構的範圍不同,往大了是企業級的,往小了說是應用架構,比如你做個需求,你的設計也是一種架構~


項目大了就要架構了吧。小東小西自己擼擼就好。


必須有,一個項目最初的時候,架構沒有選好,到後期很痛苦的!


不知所云,雖然已經自學了一年的前端,可能是我學的不用心吧。


推薦閱讀:

前端的未來: 後端會越來越同質化, 只是一個資料庫, 大部分功能都挪到前端嗎?
CSS 中,為什麼絕對定位(absolute)的父級元素必須是相對定位(relative)?
UI/UX與前端的分界,客戶(PM)與程序員的關係?
CSS 2.1 中為何規定行內塊元素的「overflow」為非「visible」時其基線是底部外邊界?

TAG:前端開發 |