<font id="zqva1"></font>
<rt id="zqva1"></rt>
  • <tt id="zqva1"></tt>
    <cite id="zqva1"></cite>

    <cite id="zqva1"><noscript id="zqva1"></noscript></cite>
      <rp id="zqva1"><meter id="zqva1"></meter></rp>

        <cite id="zqva1"></cite>
          <b id="zqva1"></b>
          <rp id="zqva1"></rp>
          <cite id="zqva1"></cite>

          <rt id="zqva1"></rt>

        1. <rp id="zqva1"></rp>

          前端工程化的的理解,淺談web工程化的開發流程

          時間:?2018-01-03閱讀:?2132標簽:?工程化

          1. 什么是前端工程化

          自有前端工程師這個稱謂以來,前端的發展可謂是日新月異。相比較已經非常成熟的其他領域,前端雖是后起之秀,但其野蠻生長是其他領域不能比的。雖然前端技術飛快發展,但是前端整體的工程生態并沒有同步跟進。目前絕大多數的前端團隊仍然使用非常原始的“切圖(FE)->套模板(RD)”的開發模式,這種模式下的前端開發雖說不是刀耕火種的原始狀態,但是效率非常低下。

          前端的工程化問題與傳統的軟件工程雖然有所不同,但是面臨的問題是一樣的。我們首先回顧一下傳統的軟件開發流程模型:

          上圖中的運行和維護并不是串行關系,也并非絕對的并行關系。維護貫穿從編碼到運行的整個流程。

          如果說計算機科學要解決的是系統的某個具體問題,或者更通俗點說是面向編碼的,那么工程化要解決的是如何提高整個系統生產效率。所以,與其說軟件工程是一門科學,不如說它更偏向于管理學和方法論。

          軟件工程是個很寬泛的話題,每個人都有自己的理解。以上是筆者個人的理解,僅供參考。

          具體到前端工程化,面臨的問題是如何提高編碼->測試->維護階段的生產效率。

          可能會有人認為應該包括需求分析和設計階段,上圖展示的軟件開發模型中,這兩個階段具體到前端開發領域,更恰當的稱謂應該是功能需求分析和UI設計,分別由產品經理和UI工程師完成。至于API需求分析和API設計,應該包括在編碼階段。


          2. 前端工程化面臨的問題

          要解決前端工程化的問題,可以從兩個角度入手:開發和部署。

          從開發角度,要解決的問題包括:

          1. 提高開發生產效率;
          2. 降低維護難度。

          這兩個問題的解決方案有兩點:

          1. 制定開發規范,提高團隊協作能力;
          2. 分治。軟件工程中有個很重要的概念叫做模塊化開發其中心思想就是分治。

          從部署角度,要解決的問題主要是資源管理,包括:

          1. 代碼審查;
          2. 壓縮打包;
          3. 增量更新;
          4. 單元測試;

          要解決上述問題,需要引入構建/編譯階段。

          2.1 開發規范

          開發規范的目的是統一團隊成員的編碼規范,便于團隊協作和代碼維護。開發規范沒有統一的標準,每個團隊可以建立自己的一套規范體系。

          值得一提的是JavaScript的開發規范,尤其是在ES2015越來越普及的局面下,保持良好的編碼風格是非常必要的。筆者推薦Airbnb的eslint規范

          2.2 模塊/組件化開發

          2.2.1 模塊還是組件?

          很多人會混淆模塊化開發和組件化開發。但是嚴格來講,組件(component)和模塊(module)應該是兩個不同的概念。兩者的區別主要在顆粒度方面。《Documenting Software Architectures》一書中對于component和module的解釋如下:

          A module tends to refer first and foremost to a design-time entity. ... information hiding as the criterion for allocating responsibility to a module.
          A component tends to refer to a runtime entity. ... The emphasis is clearly on the finished product and not on the design considerations that went into it.

          In short, a module suggests encapsulation properties, with less emphasis on the delivery medium and what goest on at runtime. Not so with components. A delivered binary maintains its "separateness" throughout execution. A component suggests independently deployed units of software with no visibility into the development process.

          簡單講,module側重的是對屬性的封裝,重心是在設計和開發階段,不關注runtime的邏輯。module是一個白盒;而component是一個可以獨立部署的軟件單元,面向的是runtime,側重于產品的功能性。component是一個黑盒,內部的邏輯是不可見的。

          用通俗的話講,模塊可以理解為零件,比如輪胎上的螺絲釘;而組件則是輪胎,是具備某項完整功能的一個整體。具體到前端領域,一個button是一個模塊,一個包括多個button的nav是一個組件。

          模塊和組件的爭論由來已久,甚至某些編程語言對兩者的實現都模糊不清。前端領域也是如此,使用過bower的同行知道bower安裝的第三方依賴目錄是bower_component;而npm安裝的目錄是node_modules。也沒必要為了這個爭得頭破血流,一個團隊只要統一思想,保證開發效率就可以了。至于是命名為module還是component都無所謂。

          筆者個人傾向組件黑盒、模塊白盒這種思想。

          2.2.2 模塊/組件化開發的必要性

          隨著web應用規模越來越大,模塊/組件化開發的需求就顯得越來越迫切。模塊/組件化開發的核心思想是分治,主要針對的是開發和維護階段。

          關于組件化開發的討論和實踐,業界有很多同行做了非常詳細的介紹,本文的重點并非關注組件化開發的詳細方案,便不再贅述了。筆者收集了一些資料可供參考:

          1. Web應用的組件化開發
          2. 前端組件化開發實踐;
          3. 大規模的前端組件化與模塊化


          3. 構建&編譯

          嚴謹地講,構建(build)和編譯(compile)是完全不一樣的兩個概念。兩者的顆粒度不同,compile面對的是單文件的編譯,build是建立在compile的基礎上,對全部文件進行編譯。在很多Java IDE中還有另外一個概念:make。make也是建立在compile的基礎上,但是只會編譯有改動的文件,以提高生產效率。本文不探討build、compile、make的深層運行機制,下文所述的前段工程化中構建&編譯階段簡稱為構建階段。

          3.1 構建在前端工程中的角色

          在討論具體如何組織構建任務之前,我們首先探討一下在整個前端工程系統中,構建階段扮演的是什么角色。

          首先,我們看看目前這個時間點(2016年),一個典型的web前后端協作模式是什么樣的。請看下圖:



          上圖是一個比較成熟的前后端協作體系。當然,目前由于Node.js的流行開始普及大前端的概念,稍后會講述。

          自Node.js問世以來,前端圈子一直傳播著一個詞:顛覆。前端工程師要借助Node.js顛覆以往的web開發模式,簡單說就是用Node.js取代php、ruby、python等語言搭建web server,在這個顛覆運動中,JavaScript是前端工程師的信心源泉。我們不討論Node.js與php們的對比,只在可行性這個角度來講,大前端這個方向吸引越來越多的前端工程師。

          其實大前端也可以理解為全棧工程師,全棧的概念與編程語言沒有相關性,核心的競爭力是對整個web產品從前到后的理解和掌握。

          那么在大前端模式下,構建又是扮演什么角色呢?請看下圖:

          大前端體系下,前端開發人員掌握著Node.js搭建的web server層。與上文提到的常規前端開發體系下相比,省略了mock server的角色,但是構建在大前端體系下的作用并沒有發生改變。也就是說,不論是大前端還是“小”前端,構建階段在兩種模式下的作用完全一致,構建的作用就是對靜態資源以及模板進行處理,換句話說:構建的核心是資源管理

          3.2 資源管理要做什么?

          前端的資源可以分為靜態資源和模板。模板對靜態資源是引用關系,兩者相輔相成,構建過程中需要對兩種資源使用不同的構建策略。

          目前仍然有大多數公司將模板交由后端開發人員控制,前端人員寫好demo交給后端程序員“套模板”。這種協作模式效率是非常低的,模板層交由前端開發人員負責能夠很大程度上提高工作效率。

          3.2.1 靜態資源構建策略

          靜態資源包括js、css、圖片等文件,目前隨著一些新規范和css預編譯器的普及,通常開發階段的靜態資源是:

          1. es6/7規范的文件;
          2. less/sass等文件(具體看團隊技術選型);
          3. [可選]獨立的小圖標,在構建階段使用工具處理成spirit圖片。

          構建階段在處理這些靜態文件時,基本的功能應包括:

          1. es6/7轉譯,比如babel;
          2. 將less/sass編譯成css;
          3. spirit圖片生成;

          以上提到的幾個功能可以說是為了彌補瀏覽器自身功能的缺陷,也可以理解為面向語言本身的,我們可以將這些功能統稱為預編譯。

          除了語言本身,靜態資源的構建處理還需要考慮web應用的性能因素。比如開發階段使用組件化開發模式,每個組件有獨立的js/css/圖片等文件,如果不做處理每個文件獨立上線的話,無疑會增加http請求的數量,從而影響web應用的性能表現。針對諸如此類的問題,構建階段需要包括以下功能:

          1. 依賴打包。分析文件依賴關系,將同步依賴的的文件打包在一起,減少http請求數量;
          2. 資源嵌入。比如小于10KB的圖片編譯為base64格式嵌入文檔,減少一次http請求;
          3. 文件壓縮。減小文件體積;
          4. hash指紋。通過給文件名加入hash指紋,以應對瀏覽器緩存引起的靜態資源更新問題;
          5. 代碼審查。避免上線文件的低級錯誤;

          以上幾個功能除了壓縮是完全自動化的,其他兩個功能都需要人工的配置。比如為了提升首屏渲染性能,開發人員在開發階段需要盡量減少同步依賴文件的數量。

          以上提到的所有功能可以理解為工具層面的構建功能。

          以上提到的構建功能只是構建工具的基本功能。如果停留在這個階段,那么也算是個及格的構建工具了,但也僅僅停留在工具層面。對比目前較流行的一些構建產品,比如fis,它具備以上所得的編譯功能,同時提供了一些機制以提高開發階段的生產效率。包括:

          1. 文件監聽。配合動態構建、瀏覽器自動刷新等功能,提高開發效率;
          2. mock server。并非所有前端團隊都是大前端(事實上很少團隊是大前端),即使在大前端體系下,mock server的存在也是很有必要的;

          我們也可以將上面提到的功能理解為平臺層面的構建功能。

          3.2.2 模板的構建策略

          模板與靜態資源是容器-模塊關系。模板直接引用靜態資源,經過構建后,靜態資源的改動有以下幾點:

          1. url改變。開發環境與線上環境的url肯定是不同的,不同類型的資源甚至根據項目的CDN策略放在不同的服務器上;
          2. 文件名改變。靜態資源經過構建之后,文件名被加上hash指紋,內容的改動導致hash指紋的改變。

          其實url包括文件名的改動,之所以將兩者分開論述是為了讓讀者區分CDN與構建對資源的不同影響。

          對于模板的構建宗旨是在靜態資源url和文件名改變后,同步更新模板中資源的引用地址

          現在有種論調是脫離模板的依賴,html由客戶端模板引擎渲染,簡單說就是文檔內容由JavaScript生成,服務端模板只提供一個空殼子和基礎的靜態資源引用。這種模式越來越普遍,一些較成熟的框架也驅動了這個模式的發展,比如React、Vue等。但目前大多數web產品為了提高首屏的性能表現,仍然無法脫離對服務端渲染的依賴。所以對模板的構建處理仍然很有必要性。

          具體的構建策略根據每個團隊的情況有所差異,比如有些團隊中模板由后端工程師負責,這種模式下fis的資源映射表機制是非常好的解決方案。本文不討論具體的構建策略,后續文章會詳細講述。

          模板的構建是工具層面的功能。

          3.2.3 小結

          構建可以分為工具層面和平臺層面的功能:

          • 工具層面
          1. 預編譯,包括es6/7語法轉譯、css預編譯器處理、spirit圖片生成;
          2. 依賴打包;
          3. 資源嵌入;
          4. 文件壓縮;
          5. hash指紋;
          6. 代碼審查;
          7. 模板構建。
          • 平臺層面
          1. 文件監聽,動態編譯;
          2. mock server。


          4. 總結

          一個完整的前端工程體系應該包括:

          1. 統一的開發規范;
          2. 組件化開發;
          3. 構建流程。

          開發規范和組件化開發面向的開發階段,宗旨是提高團隊協作能力,提高開發效率并降低維護成本。

          構建工具和平臺解決了web產品一系列的工程問題,旨在提高web產品的性能表現,提高開發效率。

          隨著Node.js的流行,對于前端的定義越來越寬泛,在整個web開發體系中。前端工程師的角色越來越重要。本文論述的前端工程體系沒有涉及Node.js這一層面,當一個團隊步入大前端時代,前端的定義已經不僅僅是“前端”了,我想Web工程師這個稱號更合適一些。

          之前跟一位前端架構師討論構建中對于模塊化的處理時,他提到一個很有意思的觀點:所謂的壓縮打包等為了性能做出的構建,其實是受限于客戶端本身。試想,如果未來的瀏覽器支持大規模并發請求、網絡延遲小到微不足道,我們還需要壓縮打包嗎?

          誠然,任何架構也好,策略也好,都是對當前的一種解決方案,并不是一條條鐵律。脫離了時代,任何技術討論都沒有意義。

          站長推薦

          1.阿里云: 本站目前使用的是阿里云主機,安全/可靠/穩定。點擊領取2000元代金券、了解最新阿里云產品的各種優惠活動點擊進入

          2.騰訊云: 提供云服務器、云數據庫、云存儲、視頻與CDN、域名等服務。騰訊云各類產品的最新活動,優惠券領取點擊進入

          3.廣告聯盟: 整理了目前主流的廣告聯盟平臺,如果你有流量,可以作為參考選擇適合你的平臺點擊進入

          鏈接: http://www.modern-decoration.com.cn/article/detial/306

          前端工程化的一些設想

          最近幾年前端工程化這個事情隨著模塊化標準(曾經的事實標準 commonjs,今天的 ES Module )的落地和工具鏈的成熟,大家普遍都在采用一體化的策略來完成工程從構建到發布的過程。

          前端工程化:構建、部署、灰度

          優秀的技術方案很多,大部分時候我們感覺只是在現有技術方案里面做排列組合、求笛卡爾積、選擇最優解,做出一個最適合當前項目的方案。未來,人類應該編寫最核心的業務代碼、設置規則

          談談前端工程化 js加載

          在沒有 前端工程化之前,基本上是我們是代碼一把梭,把所需要的庫和自己的代碼堆砌在一起,然后自上往下的引用就可以了。 那個時代我們沒有公用的cdn,也沒有什么特別好的方法來優化加載js的速度。最多用以下幾個方案。

          談談前端工程化是個啥?

          Web業務日益復雜化和多元化,前端開發已經由以WebPage模式為主轉變為以WebApp模式為主了。現在隨便找個前端項目,都已經不是過去的拼個頁面+搞幾個jQuery插件就能完成的了。工程復雜了就會產生許多問題,比如:如何進行高效的多人協作?如何保證項目的可維護性?如何提高項目的開發質量?

          聊聊前端工程化_我對工程化的理解

          工程師是個古老的職稱了。耳熟能詳的有建筑工程師,電器工程師等,往往他們在人們腦海中的印象是刻板,嚴謹,可靠。隨著互聯網的發展,軟件工程師出現了!他們不用一磚一瓦,也不用尺子電鉆,計算機是他們的施工現場,代碼是他們的工程部件

          Node.js項目拆包工程化

          在我們開發的過程中,經常會遇到這樣的問題,開發完了一些代碼或者一個接口,別的小伙伴過來問你,代碼可不可以給他復用,接口可以給他調用。這說明代碼的復用和抽象對團隊協作是很重要的

          前端工程化的淺析

          前端工程化的本質是將可以用工具來完成的事情用工具來完成。前端工程化在目前的開發中是不可逆的趨勢,每一個身處工作崗位的前端,都應該確立前端工程化的開發思維和開發方法

          web前端工程化/構建自動化

          前端工程化的概念在近些年來逐漸成為主流構建大型web應用不可或缺的一部分,在此我通過以下這三方面總結一下自己的理解。為什么需要前端工程化。前端工程化的演化。怎么實現前端工程化。

          fly63.com版權所有,內容以共享、參考、研究為目的,不存在任何商業目的。其版權屬原作者所有,如有侵權,請與小編聯系!情況屬實本人將予以刪除!

          文章投稿關于web前端網站點搜索站長推薦網站地圖站長QQ:522607023

          小程序專欄: 土味情話心理測試腦筋急轉彎幽默笑話段子句子語錄成語大全運營推廣

          国产精品高清视频免费 - 视频 - 在线观看 - 影视资讯 - 唯爱网