1. 電商前端架構設計
什麼是前端架構
說到架構，很容易拉出一系列的概念知識點，像系統架構、軟體架構、框架等等，這些不是今天探討的重點，大家可以下去網路來理解。架構的本質是什麼？其實也是一種管理。通常我們所說的管理，都是指對於任務和人員的管理，而架構管的是機器和代碼。比如說，機器的部署屬於運維的物理架構，SOA屬於服務架構，那麼，前端的架構指什麼呢？
長期以來，前端所處的位置是比較偏應用層，很薄的一層，而架構又要求深度和廣度，所以之前在前端裡面做架構，好比在小水塘里游泳，稍微撲騰兩下就到處碰壁。但最近這幾年來，隨著一些列新的技術和概念的出現，前端的范圍被大大拓展了，所以這一層逐漸變得大有可為。
單純從語言的角度來說，html、js、css是最簡單最容易上手的開發語言，不考慮模塊化、工具、壓縮優化，任何人都可以快速上手，完成一兩個功能簡單的頁面。在規模很小的項目中，前端技術要素彼此不會直接產生影響，因此無需架構相關的思考。由於前端語言這種靈活鬆散的特點，使得前端項目規模在達到一定規模後，工程問題凸顯，成為發展瓶頸，原來孤立的技術要素開始彼此產生影響，各種技術要素彼此之間開始出現關聯，要用模塊化開發，就必須對應某個模塊化框架，用這個框架就必須對應某個構建工具，要用這個工具，就必須對應某個包管理工具……這個時候，需要有人從比較高的角度去梳理、尋找適合自己團隊的集成解決方案。而這一系列解決問題的工具和手段就是所謂的前端架構。
架構不等於框架這一點很好理解，相信大家都能夠很深入的說明這里的差別，框架是架構的重要組成部分，架構決定框架的選型，框架決定架構的技術路線。架構圍繞框架進行一系列的流程工具建設，從而形成完善自動的開發體系。
+框架不等於類庫，這里就是很多人困惑的點，你用的什麼框架？jquery、underscore、linq、seajs、requirejs等等，每個人都能夠列舉一大堆。但這個是不準確的，一套編碼框架是有一系列的元素組成：開發模式，我們如何來實現代碼的職責分離。以前整個前端是mvc中v這一層，而現在前端內部也進行了mvc的邏輯細分，Javascript的MVC框架現在很多，有的強化m、有的強化c。每一個框架其實都有其特點的，並且有越來越多的創新改造，比如現在最流行的是mvvm。有angular、react等等。我們是為了引入mvvc才把他們納入到我們的開發體系，而不是因為他是一個好用的類庫。
通訊，模塊化、組件化是前端在推進開發模式過程中的一個過程產物，為了有效的進行組件隔離和獨立，現在有各種各樣的通信模型出來，不過由於實現簡單，代碼少，他往往是合入到某個類庫裡面，但本質也是一個類庫。比較成熟的比如：消息匯流排、事件模擬、緩存中轉、flux模型等等。
模板，我們用什麼樣的方式來集中的處理數據往html的轉換過程，這里就不用多展開，這種類庫現在太多了，光我們公司就有很多套，大家在代碼行、緩存管理、預編譯、運算性能、強大的語法等等各個維度不段追求各種極致。
基礎類庫最後才是傳統類庫，相信現在已經沒有同學會在項目中去約束團隊中的dom操作、常用函數、方法、非同步化等等各種很基礎東西，這個時候我們一般就是引入jq、zepto、underscor這些封裝好的東西就行了。核心就是為了改善編碼生產力。
對於框架的選型要從兩面看，一是看該框架的本領，二是看你們團隊的能耐。從經驗上給幾個點建議：
這里也可以順便展開聊一下現在前端產品的形態分類：
從這些分類裡面，我們這些年派生出了所謂全端和全棧的概念。但本質上怎麼走還是要由所在產品的形態來決定。
內容型Web站點 側重渲染方面的優化，前端邏輯比重小
操作型B/S系統 以數據和邏輯為中心，界面較規整
hybrid內置型，要處理緩存和一些本地介面，包括PC客戶端和移動端。現在的本地應用，基於很多考慮，都變成了混合應用，也就是說，開發這個應用的技術，既包含原生的代碼，也包含了嵌入的HTML5代碼
Web游戲，前端的邏輯非常重，在代碼結構上要求非常高的可管理性和更復雜的設計模式。
桌面應用型，現在有一些PC端的混合應用開發技術，比如node-webkit和hex，前者的典型應用是XDK，後者的典型應用是有道詞典，此外，豌豆莢的PC客戶端也是採用類似技術的，也有一些產品是用的qt-webkit。這類技術可以方便做跨平台，極大減少開發工作量。
大工程應該盡量避開谷歌產品，他的很多技術開源項目都是玩票性質的，GWT、Closure、Darty就是前車之鑒。曾今提出過很多的新技術，到現在還是獨家的，變出太大。包括現在angular，喜歡做斷崖式升級，做做運營後台系統問題不大，如果是線上系統的話，每次升級就是一次人月神話中的典型焦油坑。
關注應用場景，像剛才說到的boss後台是一種；另外我的平台是否有沉重的歷史包袱，需要兼容ie6，還是可以輕裝上陣；產品對於seo是什麼樣的態度？是否需要考慮自適應？或者我的團隊足夠大，能夠各搞一套？；產品特徵是強內容還是強交互或者是游戲性。這些都是選擇不同框架的主要出發點。
沒有最好，只有最適合自己的，基本上，針對每個平台，我們都可以列出一些主流框架，但不意味著你們都能駕馭得住。小馬過馬，老牛沒過膝，松鼠淹個半死，就是這么回事。但無論我們選擇什麼框架或決定自己動手造輪子，都勿忘初心，技術必須讓我們工作生活更為輕松愉快——我們只選擇我們能駕馭住的框架，我們不能保證它在一年後是否會過時落後。
而且按照我個人這么多年的經驗來看，任何框架都會過時，往往不是因為他不夠好，而是因為一定有更好的出來。我們再選擇一個框架或者一個類庫的時候就要想好，未來我如何拋棄他。至少不能成為我們引入新的框架的絆腳石。現實的工作中很多的團隊往往會陷入到年復一年的用今年的新框架去重構去年老框架代碼的歷史循環中去。對於引入框架如何盡量延長他的生命力，我個人的意見是選擇框架時去追求概念，而不是潮流，當我的架構可以接受新的設計概念的時候才去考慮引入新的框架。用設計理念的選擇代替框架的選擇。之所以這么說是因為我觀察到我們部門的後端架構的開發理念跟我進公司的時候是差不多的。更多你可以參考成都網站建設
架構的組成
組件框架
2. 什麼是"前端工程化"
前端工程化是指使用軟體工程的技術和方法來進行前端的開發流程、技術、工具、經驗等規范化、標准化。其主要目的為了提高效率和降低成本，即提高開發過程中的開發效率，減少不必要的重復工作時間。
前端工程化是前端架構中重要的一環，主要就是為了解決上述大部分問題的。而前端工程本質上是軟體工程的一種，因此我們應該從軟體工程的角度來研究前端工程。
前端工程化有四個特點：模塊化、組件化、自動化、規范化。
1、模塊化：
就是將一個大文件拆分成相互依賴的小文件，再進行統一的拼裝和載入。只有這樣，才有多人協助的可能。在工程化之前，一直是使用js、jquery、ajax，這沒有模塊概念，對於開發大型且復雜的系統會有一定的限制。
2、組件化：
組件化≠模塊化。模板化只是在文件層面上，對代碼和資源的拆分；組件化是在設計層面上，對於UI的拆分。目前市場上的組件化框架最多，主要的有Vue，React，Angular2。
3、自動化：
「簡單重復的工作交給機器來做」，自動化也就是有很多自動化工具代替我們來完成，例如持續集成、自動化構建、自動化部署、自動化測試等等。
4、規范化：（至關重要的一環）
在項目規劃初期制定的好壞對於後期的開發有一定影響。包括的規范有：
目錄結構的制定、編碼規范、前後端介面規范、文檔規范、組件管理、Git分支管理、Commit描述規范、定期codeReview、視覺圖標規范。
(2)前端模塊化組件化擴展閱讀：
為什麼需要前端工程化：
前端越來越復雜，設計的問題和環節也越來越多，不採用工程化管理，就無法很好的實現團隊協同和降低復雜性。 原因如下：
1、前端范疇不斷擴大
早期的前端只需要適配桌面瀏覽器，而現在的前端，需要適配不同類型和尺寸的設備，包括移動端網頁，app應用等。
2、前後端分離
早期的前端只是後端 MVC 框架的一層模塊， 而現在的前端普遍是從後端介面獲取數據，編寫處理邏輯，各種前端mvc前端框架也層出不窮。
3、模塊化開發的出現
現在的前端開發不再是從零寫起，重復造輪子，而是會引用大量內部和外部的組件和模塊，這也導致前端必須進行模塊管理。
4、轉碼器的盛行
為了提高效率，前端工程往往不會直接寫html,css,和js代碼，而是改用其他格式書寫，再用工具編譯為目標格式。
比如用Jade 寫HTML，用less、sass、stylus 編寫CSS,用ES6、Typescript編寫JavaScript。
5、開發流程和團隊
早期的前端團隊往往只有幾個人，而現在的前端團隊可以擴展到幾十人，甚至上百人。每個人只負責自己的一塊內容。所以，如何協調多人多團隊的工作，保證溝通順暢，保證許可權管理，越來越成為一大問題。
前端工程化的具體內容：
1、代碼規范: 保證團隊所有成員以同樣的規范開發代碼。
2、分支管理: 不同的開發人員開發不同的功能或組件，按照統一的流程合並到主幹。
3、模塊管理: 一方面，團隊引用的模塊應該是規范的;另一方面，必須保證這些模塊可以正確的加入到最終編譯好的包文件中。
4、自動化測試：為了保證和並進主幹的代碼達到質量標准，必須有測試，而且測試應該是自動化的，可以回歸的；
5、構建：主幹更新以後，自動將代碼編譯為最終的目標格式，並且准備好各種靜態資源；
6、部署：將構建好的代碼部署到生產環境。
3. 前端如何提升開發效率
來具體聊一聊提高前端工程師開發效率的那些方法！
當然除了以上5點，對於前端來說需要提高開發效率的地方還有很多，可謂任重而道遠。希望以上幾點能夠給初識前端的同學帶來啟發並能夠親自實踐。
4. 如何理解前端模塊化
前端模塊化
在JavaScript發展初期就是為了實現簡單的頁面交互邏輯，寥寥數語即可；如今CPU、瀏覽器性能得到了極大的提升，很多頁面邏輯遷移到了客戶端（表單驗證等），隨著web2.0時代的到來，Ajax技術得到廣泛應用，jQuery等前端庫層出不窮，前端代碼日益膨脹
這時候JavaScript作為嵌入式的腳本語言的定位動搖了，JavaScript卻沒有為組織代碼提供任何明顯幫助，甚至沒有類的概念，更不用說模塊（mole）了，JavaScript極其簡單的代碼組織規范不足以駕馭如此龐大規模的代碼
模塊
既然JavaScript不能handle如此大規模的代碼，我們可以借鑒一下其它語言是怎麼處理大規模程序設計的，在Java中有一個重要帶概念——package，邏輯上相關的代碼組織到同一個包內，包內是一個相對獨立的王國，不用擔心命名沖突什麼的，那麼外部如果使用呢？直接import對應的package即可
import java.util.ArrayList;
遺憾的是JavaScript在設計時定位原因，沒有提供類似的功能，開發者需要模擬出類似的功能，來隔離、組織復雜的JavaScript代碼，我們稱為模塊化。
一個模塊就是實現特定功能的文件，有了模塊，我們就可以更方便地使用別人的代碼，想要什麼功能，就載入什麼模塊。模塊開發需要遵循一定的規范，各行其是就都亂套了
規范形成的過程是痛苦的，前端的先驅在刀耕火種、茹毛飲血的階段開始，發展到現在初具規模，簡單了解一下這段不凡的歷程
函數封裝
我們在講函數的時候提到，函數一個功能就是實現特定邏輯的一組語句打包，而且JavaScript的作用域就是基於函數的，所以把函數作為模塊化的第一步是很自然的事情，在一個文件裡面編寫幾個相關函數就是最開始的模塊了
function fn1(){
statement
}
function fn2(){
statement
}
這樣在需要的以後夾在函數所在文件，調用函數就可以了
這種做法的缺點很明顯：污染了全局變數，無法保證不與其他模塊發生變數名沖突，而且模塊成員之間沒什麼關系。
對象
為了解決上面問題，對象的寫法應運而生，可以把所有的模塊成員封裝在一個對象中
var myMole = {
var1: 1,
var2: 2,
fn1: function(){
},
fn2: function(){
}
}
這樣我們在希望調用模塊的時候引用對應文件，然後
myMole.fn2();
這樣避免了變數污染，只要保證模塊名唯一即可，同時同一模塊內的成員也有了關系
看似不錯的解決方案，但是也有缺陷，外部可以隨意修改內部成員
myModel.var1 = 100;
這樣就會產生意外的安全問題
立即執行函數
可以通過立即執行函數，來達到隱藏細節的目的
var myMole = (function(){
var var1 = 1;
var var2 = 2;
function fn1(){
}
function fn2(){
}
return {
fn1: fn1,
fn2: fn2
};
})();
這樣在模塊外部無法修改我們沒有暴露出來的變數、函數
上述做法就是我們模塊化的基礎，目前，通行的JavaScript模塊規范主要有兩種：CommonJS和AMD
CommonJS
我們先從CommonJS談起，因為在網頁端沒有模塊化編程只是頁面JavaScript邏輯復雜，但也可以工作下去，在伺服器端卻一定要有模塊，所以雖然JavaScript在web端發展這么多年，第一個流行的模塊化規范卻由伺服器端的JavaScript應用帶來，CommonJS規范是由NodeJS發揚光大，這標志著JavaScript模塊化編程正式登上舞台。
定義模塊
根據CommonJS規范，一個單獨的文件就是一個模塊。每一個模塊都是一個單獨的作用域，也就是說，在該模塊內部定義的變數，無法被其他模塊讀取，除非定義為global對象的屬性
模塊輸出：
模塊只有一個出口，mole.exports對象，我們需要把模塊希望輸出的內容放入該對象
載入模塊：
載入模塊使用require方法，該方法讀取一個文件並執行，返迴文件內部的mole.exports對象
5. web前端學完css，js,會寫基本的網站了，接下來該學哪個框架
http基礎知識，jquery+bootstrap之類的快速構建，設計模式思想，框架思想如reactjs/angular/vue.js,前端工程化，包括代碼規范，模塊化(CommonJS,AMD,UMD,ES2015 Moudle)，css模塊化（主要是SASS,LESS的mixin)，前端自動化（如gulp自動化，webpack打包），前端組件化（reactjs之類的組件化思想），版本控制管理，前端黑客攻防，數據可視化，HTML5游戲開發，圖形學/圖形演算法，Nodejs全棧開發，React native之類的安卓/ios開發等等。很多，前端知識量增長速度之快，變化之迅速，需要你我不斷學習，保持一顆熱情的心。
6. 如何實現項目的模塊化（組件化）開發，最近的做這個
，產品形態五花八門，涉獵極廣，什麼高大上的基礎庫/框架，拽炫酷的宣傳頁面，還有屌炸天的小游戲……不過這些一兩個文件的小項目並非是前端技術的主要應用場景，更具商業價值的則是復雜的Web應用，它們功能完善，界面繁多，為用戶提供了完整的產品體驗，可能是新聞聚合網站，可能是在線購物平台，可能是社交網路，可能是金融信貸應用，可能是音樂互動社區，也可能是視頻上傳與分享平台……
7. 什麼叫組件化開發
張克軍 提出的「組件化就是函數式界面開發」這一說法我是難以接受的，函數式界面開發就讓它好好地叫「函數式組件化」吧，不然我們會在所謂的「傳統UI框架」和「函數式界面開發」之間出現一個Gap，豈不是又要造個詞給填上，多累……
我前面說會有一個Gap，這個Gap很可能就是我們現在想用「組件化」這個定義去表達的一些點，我想在此做一些個人的見解
我將之理解為以下幾要素：
組件是對邏輯的封裝，不限於圖形元素。即我們可以把if做成組件、把一個倒計時做成組件、把一段動畫做成組件、把路由做成組件、把數據架構做成組件，而這些並不能稱為控制項
組件具備單個可移植性，即「隨載入隨用」，不需要為其准備復雜的基礎條件（如引入樣式、引入框架等）。然而這一點現有那些所謂組件庫做得並不好，技術上也不大現實
組件是聲明式定義的，而非命令式。這個不想多說，很大程度上是自己主觀的一個想法
而上面最重要的就是第一點，所以要問我什麼是「組件化開發」，我的說法是：
把圖形、非圖形的各種邏輯均抽象為一個統一的概念（組件）來實現開發的模式
這與傳統開發框架的最大區別就是統一了圖形元素與非圖形元素，除此之外我再想不出其它真正體現區別的點了
在這個概念下，包括router、ajax、mole loader、timer、animation、interval等，都是組件，共享統一的生命周期管理和對外介面，且都是聲明式地進行組合
我的一位同事告訴我去年的深JS上，有位淘寶的朋友的話題叫做「前端組件服務化」，這裡面提的那些個概念，是很符合我對「組件化」的認識的，他要是不給再強安個「服務化」的噱頭就好了- -
不過話說回來，在這個要求之下，組件其實不是那麼好進行抽象設計的，隨便說幾個例子，有難的也有簡單的：
非圖形元素的各種需求如何統一介面，如timer和ajax
組件可以橫向組件，但是縱向復用如何解決，如希望任何圖形元素都可以實現被滑鼠拖拽的效果，則滑鼠拖拽應該也是個組件，這個組件與其它組件的關系是什麼
有些組件對其可被組合的組件是有要求的，比如HTML里就不大好意思把一個<p>放進一個<span>里，這一點如何在組件上表達（實現不難，表達比較難）
一些我們原本想當然認為純的小函數的東西，是不是也能當組件玩，比如underscore.pick要不要也是個組件
8. 怎樣提高前端工程師開發效率，都在這里
前端工程師其實是一個工作很雜的職位，除了要負責切圖、寫html/css/js外，還要解決一系列的瀏覽器兼容性、網頁性能優化等問題，所以提高前端工程師的開發效率是勢在必行的，也是前端工程化的體現。
對於開發效率，我個人理解是
開發效率 = 新增代碼的效率 + 修改代碼的效率 + 維護代碼的效率
那麼如何提高前端開發效率便可以按照前端工程化的理念來進行劃分。下面我就介紹下7個提高前端開發效率的方法。
1.切圖
切圖是一個前端最基礎的技能，一般我們使用Photoshop或者FireWorks基本都能搞定設計師交付給我們的設計圖，但是要提高切圖效率的話就得使用一些訣竅了，比如利用PS里的動作來實現「一鍵切圖」功能，這里除了切圖外還介紹了其他的實用方法和工具。
2.編碼
對於編寫代碼部分我們首先要找到一款合適自己的IDE工具，建議不要使用Notepad++或者Dreamweaver，這些工具已經不符合前端潮流了，無法讓自己優雅地敲代碼。這里我主要推薦Sublime Text、Atom或者Webstrom，因為它們除了人性化的界面和支持大多數語法的高亮外，還可以安裝各種各樣的插件來拓展你的IDE工具，下面我主要介紹幾款Sublime Text提高開發效率的插件：
其中Element是用於快速編寫html/CSS的，比如輸入 ul>li 後按下tab鍵便可以生成一個ul標簽裡麵包含一個li標簽
JSFormat用於格式化JS；CSScomb用於對樣式屬性進行一鍵排序；HTML-CSS-JS Prettify可以一鍵規范我們的HTML/CSS/JS，甚至JSON格式；SublimeTmpl可以快速新建HTML/CSS/JS文件; ColorPicker用於調用本地調色板功能。這些工具都非常實用，一定程度上可以提高我們的編碼效率。
3.自動化
說到提高開發效率，這里不得不提一些前端的自動化工具，畢竟前端自動化是目前及未來的趨勢，能夠很大程度上縮減前端不必要的工作量，使我們能夠專注前端本身。
這里我們可以使用NPM來管理我們的項目包文件；利用webpack來打包壓縮我們的代碼；利用Node.js來實現構建本地伺服器；利用Karma、Jasmine來測試我們的前端代碼。
用好前端自動化工具可以幫助我們處理很多瑣碎的事情，比如一鍵壓縮代碼、圖片，一鍵合並JS，檢測文件更新等。
4.模塊化
隨著web2.0時代的到來，Ajax技術得到廣泛應用，前端代碼日益膨脹，而前端模塊化能夠方便我們對項目代碼的維護，進行按需載入，從長遠角度來看對我們提高項目的開發效率同樣大有益處。
在ES6出來之前應該說前端代碼本身不具備實現模塊的功能，我們必須要使用一些模塊化載入器來實現，比如RequireJS、SeaJs等。而隨著ES6的普及，目前像RequireJS、SeaJs這樣的工具已經沒有存在的必要了。所以在基於ES6的開發環境下我建議使用ES6的模塊化功能來實現我們的前端模塊化。
5.組件化
前端組件化的概念也是由來已久，我們可以通過將我們的代碼劃分成不同組件來實現功能公用，一個同樣的功能我們可能不用再次編寫相同的代碼，同時也可以提高前端代碼的可維護性和清晰度。以下是目前流行的前端框架Vue的單文件組件的概念圖：
我們可以將公用的組件抽離，將大組件拆分成小組件的形式實現前端組件化，組件與組件之間可以存在父子關系，也可以存在兄弟關系。在Vue的單文件組件中，一個組件包含了其HTML、CSS、JS的代碼片段。
6.前後端分離
前後端分離的項目對提升前端開發效率非常有幫助，因為前端不再需要後台配置路由、搭建伺服器環境、編寫模板等，這樣一來前端的生產力就會得到很大程度的解放，但是前後端分離的項目有利也有弊，如下圖所示：
最終我們需要根據項目需求衡量利弊來決定是否使用前後端分離的模式。
7.規范與模式
團隊協作離不開編碼規范和開發模式的幫助。遵循編碼規範文檔可以幫助我們在團隊開發時提高合作開發的效率。一個團隊遵循一套編碼規范可以使每個人的代碼寫出一個人的風格，這樣團隊間相互審查、測試、完善功能時會非常高效。下方是一些開源的前端編碼規範文檔：
網頁鏈接
首頁-TGuide
網頁鏈接
網頁鏈接
除了編碼規范我們在開發時經常會沿襲了一些已經存在的模式來解決問題，比如當用JS編寫彈框時我們往往會用到單例模式，用CSS編寫動畫時直接套用動畫的常用屬性等，我們不再需要從頭開始思考某一個功能的實現，這就是模式帶來的意義。
結語
當然除了以上7點，對於前端來說需要提高開發效率的地方還有很多，可謂任重而道遠。只有將前端無序、繁雜的操作組織起來，利用工具簡化、規范前端流程，才能實現項目構建、開發、維護的一體化。希望本文能夠給初識前端的同學帶來啟發並付諸實踐。
9. 模塊化和組件化的區別
組件和模塊的定位不同。組件一般用於前端,模塊化在後台運用的比較多。例如vue中的組件,主要是為了拆分vue實例的代碼量,讓我們可以以不同的組件來劃分不同的功能模塊,將來我們需要什麼樣的功能,就直接調用對應的組件即可。
10. 在前端中什麼是組件化 什麼是模塊化
模塊化更一種開發規范，比如cmd amd 是為了更好的解藕，比如一個網站，按照不同的模塊來開發，比如你有個評論區，a 項目有，b 項目有，如果僅是單純的模塊開發，這個js 文件你就可以單獨來回引用，
更比如 ，一個頁面 分好多個功能， 這時候你要是都寫在一個js 中 會越來越大，
而你把他分成不同的模塊，
比如評論是一塊
分頁又是一塊，
已經上線，或你不做了，後期別人拉手，或你接手別人的項目， 這時候來個需求讓你把分頁去掉，或修改 你可以清楚的找到對應模塊文件 進行修改 或去掉
模塊是自定義的，
組件，更想當於一個通用的東西，有的分功能組件，有的分業務組件
大圖切換，這種就是單純的一個效果展示，只要調用就ok
一個分頁，也是只單純的調用，
組件更是一個多處都可以使用 ，不需要再單獨開發的