前端架構(gòu)——從入門到微前端 讀書筆記
最近耐齐，前端圈中出現(xiàn)一個一個熱詞”微前端“浪秘，作為一個前端菜鳥蒋情，也來趕趕集。
所以耸携，我讀了黃蜂達老師寫的《前端架構(gòu)——從入門到微前端》一書棵癣。
概要
這本書主要講的是， 對于一個前端項目夺衍，在項目不斷迭代的過程中狈谊，對整個項目的工作流、構(gòu)建流沟沙，已經(jīng)對一個項目的技術(shù)選型河劝，已經(jīng)后期的基礎(chǔ)設(shè)施的建設(shè)進行了一個講解。并且矛紫，在后面第九到第十章中赎瞎，講解了微前端。
最近今年里颊咬，前端成為軟件行業(yè)中一個獨立的職業(yè)务甥，從小的創(chuàng)業(yè)公司到大的上市公司，都有自己的前端技術(shù)人員甚至是一個團隊喳篇。在業(yè)務(wù)不斷變化中敞临，代碼量越來越大，工程化成為必然的問題麸澜。這本書挺尿，對于目前前端的現(xiàn)狀，以及前端的工程化進行的詳細的講述炊邦。但作為前端萌新 的编矾，只能領(lǐng)略一二，在以后的項目中需要慢慢理解铣耘。下面是我讀書后一些記錄洽沟。
前端項目的構(gòu)建，工作流蜗细，以及架構(gòu)實施
因為要關(guān)注行情裆操，了解市場的需求，我偶爾回去逛逛boss直聘等招聘網(wǎng)站炉媒。發(fā)現(xiàn)踪区，現(xiàn)在的前端已經(jīng)像過去一樣，只會寫樣式吊骤、html或者切圖缎岗。幾乎每個招聘上都會有以下這樣的要求：
掌握一門后端語言
有navtive開發(fā)經(jīng)驗更佳
了解前端工程化 會使用 webpack gulp這樣的工具
……
如今的前端已經(jīng)變成軟件行業(yè)中重要的一部分。
所以白粉，逃不開的就是传泊，工程化鼠渺，質(zhì)量管理，架構(gòu)等一系列問題眷细。
1. 軟件架構(gòu)的一些基本常識
首先拦盹，一個架構(gòu)我們要去考慮什么
系統(tǒng)間的關(guān)系，需要明確當(dāng)前的系統(tǒng)與其他系統(tǒng)間的關(guān)系是調(diào)用關(guān)系還是依賴關(guān)系等
系統(tǒng)內(nèi)的關(guān)系溪椎，系統(tǒng)內(nèi)各個子系統(tǒng)的之間普舆，接口是什么，他們是如何通信的
規(guī)范和原則校读，用于開發(fā)人員的溝通的基礎(chǔ)沼侣，這是一個架構(gòu)中必須包含的一項，可以是文檔或者口頭約束歉秫。
其次蛾洛，在架構(gòu)中要明確需求，及其利益相關(guān)人員或者部門端考，可能不同人員或者部門關(guān)注的點不用雅潭。例如：
產(chǎn)品或者業(yè)務(wù)負責(zé)人員關(guān)心的是能否按時上線已經(jīng)，未來如何進程產(chǎn)品的迭代
項目經(jīng)理確定項目計劃和人選
開發(fā)人員却特，關(guān)心架構(gòu)的演進和維護
測試人員，是否可以自動測試筛圆，或者將測試自動地集成到項目中
對于前端人員裂明，我們還要明確，瀏覽器支持的范圍以及太援，移動端可以支持的版本等闽晦。
常見的架構(gòu)風(fēng)格
- 分層風(fēng)格
一個系統(tǒng)由多層構(gòu)成，每個層有不同的模塊
- MVC架構(gòu)風(fēng)格
這個風(fēng)格強調(diào)職責(zé)分離提岔，將軟件系統(tǒng)分為三個基本部分: 模型（Model）, 視圖（View）仙蛉，控制器（Controller）。視圖和模型通過控制器進行交互碱蒙，保證用戶界面與書模型是一致的荠瘪。
- 發(fā)布-訂閱風(fēng)格
這種風(fēng)格可以成為稱作基于事件的架構(gòu)風(fēng)格。其最大的好處是代碼上的解耦赛惩。在前端的開發(fā)過程中哀墓，為了解耦不同UI組件的依賴，會經(jīng)常采用這種模式喷兼。
- 管道和過濾器
這是一種適合于處理數(shù)據(jù)流的架構(gòu)模式篮绰，它將每個步驟都封裝在一個過濾器組件中，數(shù)據(jù)通過相鄰過濾器之間的管道傳輸季惯。最典型的管道過濾器架構(gòu)師UNIX shell的設(shè)計吠各。 在類Unix系統(tǒng)中臀突，使用’|‘作為管道符號，當(dāng)我明年需要編寫復(fù)雜的shell腳本來處理內(nèi)容時贾漏，便會使用這個符號惧辈。例如’ ls-l|grep.jpg’，便會先執(zhí)行l(wèi)s-l命令磕瓷，再將結(jié)果交由grep程序盒齿，查找以.jpg結(jié)尾的文件名。
前端架構(gòu)的層次設(shè)計
下面是一個圖（原圖參考書籍：p：22）
2. 前端架構(gòu)的實施過程
光有概念還不行困食，需要把它們轉(zhuǎn)化為一套可以落地的理論边翁。首先看下我們一個企業(yè)項目的進行周期
下圖是一個項目的啟動和實施周期（p：28）
了解了開發(fā)周期，就需要通過每個周期中不同的特點進行資源的調(diào)配硕盹。
例如：當(dāng)我們進入業(yè)務(wù)回補期符匾，我們當(dāng)前要面對第一次deadline，這個時候雖然業(yè)務(wù)開發(fā)已經(jīng)進入正軌瘩例，但是于是工作優(yōu)先級啊胶，變成了業(yè)務(wù)第一，工作第二垛贤。
或者焰坪，當(dāng)我們部署上線成功，并且正常進行業(yè)務(wù)迭代時聘惦，我們就需要考慮提升團隊能力來獲取更好的開發(fā) 效率等等某饰。
3. 重要的工作——設(shè)計工作流和構(gòu)建流
在我剛步入工作的時候，接觸的項目是多頁面應(yīng)用善绎，用jquery然后html5 黔漂，就是手寫文件，在瀏覽器上打開文件禀酱，沒寫一行CSS就需要手動刷新一下炬守。當(dāng)項目完成是，就交個后端剂跟，后端會用腳本拷貝到nginx相應(yīng) 的目錄下减途。
后來接觸到vue，知道了有cli這么個東西浩聋。
到目前為止观蜗，市場上出現(xiàn)”云效“等軟件。
在這個過程中衣洁，我?guī)缀醪恢缹τ谝粋€前端來說什么是運維墓捻，或者構(gòu)建流。
這本書中用了兩大章的內(nèi)容，來說工作流和構(gòu)建流砖第，下面我分開說一下撤卢。
工作流
工作流，就是在工作中可以使用一些腳本或者自己開發(fā)一些有用的工具梧兼，幫助我們減少重復(fù)的勞動放吩，降低出錯率。
在工作中羽杰，我們可以注意一下幾個方面渡紫，
- 構(gòu)建基礎(chǔ)規(guī)范，包括一些基本是書寫規(guī)范
前期考赛，如果在團隊比較小情況下惕澎，可以通過后頭來約束。但是颜骤，當(dāng)團隊發(fā)展到一定規(guī)模唧喉，就需要通過文檔，自動化（eslint等）忍抽，以及代碼評審來規(guī)范八孝。
再這樣的情況下，便于新人更快的融入到開發(fā)當(dāng)中鸠项，以及可以約束同事產(chǎn)出更好的代碼并且使得項目維護更加方便干跛。
- 可以使用一些預(yù)編譯器，來加快我們的開發(fā)效率锈锤，例如es6驯鳖，es7等語法，或者typescript久免。對于css有sass，less等
- 統(tǒng)一的開發(fā)工具扭弧，統(tǒng)一的開發(fā)工具有利于阎姥，可以通過使用工具中的插件來提升開發(fā)效率，并且不需要學(xué)習(xí)鸽捻。但我個人喜歡用不同的工具呼巴，目前用的最多的有vscode 以及webstrom 。并且兩個工具各有優(yōu)劣御蒲。例如衣赶，vscode更佳簡單輕便有很多插件可以隨時插拔，并且是free的 厚满。但是府瞄，我再使用vscode的git相關(guān)插件中，總會出現(xiàn)一些問題碘箍。在這點webstrom會更好一些遵馆，我比較喜歡使用webstrom的git對比工具鲸郊，每當(dāng)有不該合并的代碼混入時，我可以通過比對货邓，輕松將代碼分離開來秆撮。
- 值得注意的是項目中的文檔
項目中的文檔可以分為獨立的文檔，已經(jīng)代碼中的文檔换况，兩者相結(jié)合可以達到很好的效果职辨。我認為，在開發(fā)新需求的同時戈二，開發(fā)文檔也應(yīng)該是工作中不可缺少的一部分舒裤。通過文檔可以讓隊友很好的理解你當(dāng)初的設(shè)計思路，或者比如說挽拂，日后在重構(gòu)的時候惭每，可以很清楚代碼的邏輯以及為什么要這么寫。
除了單獨的文檔亏栈，還有注釋台腥，代碼提交記錄以及相應(yīng)的描述都可以成為很好的文檔。
- 測試
測試是很好保證代碼質(zhì)量的一個手段绒北，通過寫測試可以更好的理解代碼和邏輯黎侈，并可以在適當(dāng)?shù)臅r候為重構(gòu)或者修復(fù)bug時防止，其他功能被篡改闷游。
測試從下往上主要有單元測試峻汉，組件測試，服務(wù)測試脐往，e2e測試休吠。
構(gòu)建流
有了工作流之后，我們需要將我們业簿，我們的源代碼通過構(gòu)建瘤礁，發(fā)布到服務(wù)器上。
對于一個小的梅尤，不需要任何依賴項目柜思，我們只需要將我們編寫的js，css巷燥，html放在一個文件夾里赡盘，然后丟到服務(wù)器上。幾乎缰揪，沒有什么構(gòu)建流可言陨享。但，我們項目越來越復(fù)雜我們必須關(guān)注以下一些問題。
- 依賴管理工具
目前而言霉咨，我們主要使用npm蛙紫，npm主要基于commenJS來實現(xiàn)。在構(gòu)建的過程中途戒，可能會通過其他形式來引入坑傅，因為，commenJs并是在nodejs中運行的包管理機制喷斋，它并不適合用于移動端唁毒。
這里有一個重要的問題，就是nodeJS跨平臺的問題星爪，有些nodeJS依賴包浆西，為了優(yōu)化性能，將一部分功能使用C++編寫顽腾，而C++代碼再node中運行的時候近零，需要編譯。編譯的過程會存在抄肖，操作系統(tǒng)或者久信，npm版本不兼容的問題。
- 構(gòu)建的目標(biāo)
根據(jù)場景不同漓摩，構(gòu)建是一個復(fù)雜的話題裙士，但基本項目離不開以下一些文件
? a. 用于管理運行時（如路由懶加載）的runtime.js文件
? b.樣式相關(guān)的style.css
? c. 解決JavaScript在不同瀏覽器兼容問題polyfills.js
? d. 程序相關(guān)的main.js
在文件打包時，除了進行代碼的編譯管毙、打包腿椎、還要對css，js等靜態(tài)文件進行重命名等夭咬。
-
設(shè)計構(gòu)建流
- 明確任務(wù)啃炸，就是需要做什么，例如npm build是打包卓舵，npm test是測試
- 步驟拆解肮帐，將任務(wù)拆解為一些步驟
- 展現(xiàn)形式，我們大多數(shù)是一個網(wǎng)站边器，但有些項目例如一個組件庫，需要的是文檔以及示例
- 插件托修，在構(gòu)建的時候忘巧，一般會選用插件，使用插件能更高效睦刃，在選用插件的時候砚嘴，確定構(gòu)建的可行性
明確上述后，我們需要使用工具對其進行自動化
目前，常用的工具有g(shù)lup grunt webpack等际长，不同的工具優(yōu)劣不同耸采，使用場景也不同。
對于工育，使用框架的項目虾宇，一般情況框架都提供的相應(yīng)的cli，只需要進行簡單的定制如绸。
持續(xù)集成
對于構(gòu)建好的目標(biāo)文件嘱朽，則需要進行部署。以下為三種部署方式：
- 持續(xù)部署怔接，構(gòu)建完成即部署搪泳，常見于測試環(huán)境
- 自動化部署，在持續(xù)部署的基礎(chǔ)上稍微進行弱化扼脐，即需要人為的介入才能自動化部署
- 手動部署岸军，即需要全程人為介入的部署流程
對于自動化部署，我們需要選取適當(dāng)?shù)墓ぞ咄呶辏鏹enkins等幫助我們完成艰赞。同時，部署的時候需要脏榆，進行環(huán)境配置猖毫。例如將http請求從本地的mock Server指向后端服務(wù)等。
還有一件事情须喂，就是我們需要寫一些調(diào)試的代碼吁断，為了捕獲難于察覺的bug，通常會有一些額外的開關(guān)來獲取我們需要的調(diào)試數(shù)據(jù)坞生。如：
- 在url中添加一些參數(shù)仔役，在前端代碼運行時去讀取這些參數(shù)
- 對特定的賬號進行權(quán)限處理，以獲取調(diào)試功能是己。
多頁面應(yīng)用與單頁面應(yīng)用
我認為又兵，假設(shè)你所擁有的工具只有一個錘子時， 把所有的事物都當(dāng)做釘子來對待是很有吸引力的卒废。
——錘子定律
1. 為什么不使用單頁面應(yīng)用
對一個前端工程師來說沛厨，拿到一個項目要去實現(xiàn)它，無非用兩種方式
- 使用多頁面摔认，包括服務(wù)端使用模板引擎進行渲染逆皮，或者使用類似jquery的js庫
- 使用單頁面框架，目前流行的vue参袱，react电谣，angular
書中作者通過三個方面來闡述多頁面應(yīng)用的優(yōu)勢秽梅，分別是：構(gòu)建成本，學(xué)習(xí)成本剿牺，后臺渲染成本企垦，架構(gòu)的復(fù)雜性。
構(gòu)建成本
對于一個多頁面系統(tǒng)來說晒来，幾乎不需要什么構(gòu)建钞诡，因為，不論是html代碼或者后端通過jsp或者asp等動態(tài)產(chǎn)生的html代碼都是可以直接在瀏覽器中運行的潜索。
但是臭增，單頁面就沒有那么順利。目前的單頁面系統(tǒng)中幾乎都使用了虛擬dom技術(shù)竹习，我們在開發(fā)中產(chǎn)出的是誊抛，vue的template模板語言，或者是jsx整陌。但是它們在瀏覽器中運行的卻是拗窃，可以返回一個對象的render函數(shù)，這個對象是一個虛擬dom的對象泌辫，經(jīng)過一系列復(fù)雜的操作將其渲染為真實的dom随夸。
所以，當(dāng)將一個.vue文件或者.jsx文件變成render函數(shù)時震放，就產(chǎn)生了構(gòu)建成本宾毒。即使目前已經(jīng)有成熟的工具可以使用，例如vue-loader, 或者babel.js殿遂。但是诈铛，跟多頁面比起來，這些”黑盒工具“（vue-loader,babel.js等）在一定程度上會帶來一些成本墨礁，與維護的風(fēng)險幢竹。
學(xué)習(xí)成本
就目前我們前端開發(fā)中常用的單頁面框架（vue, react, angluar）, 每一種框架都有詳細的文檔，以及強大的社區(qū)恩静。特別是最近比較火的vue焕毫，我們在編寫的時候，感覺就好像是編寫原生的html代碼驶乾，對于一個小團隊或者團隊的技術(shù)儲備不夠扎實的時候邑飒，直接是首選。
但是级乐，使用久了就會發(fā)現(xiàn)幸乒，要構(gòu)建一個復(fù)雜的項目，需要對其原理有一個深入的理解才可以唇牧，這個過程無形中增加了許多學(xué)習(xí)成本罕扎。
后臺渲染成本
書中談到這個，主要是說目前的一單頁面框架在面對SEO（Search Engine Optimization）的情況丐重，作為單頁面系統(tǒng)腔召，需要將dom渲染挪到服務(wù)端去，這樣就增加看服務(wù)端渲染的成本扮惦。如果是臀蛛，用原生的html開發(fā)的網(wǎng)站就不存在這個問題。
除此之外崖蜜，使用多頁面應(yīng)用浊仆，還有個好處就是，在面對在對兼容性有要求的項目中體現(xiàn)出的優(yōu)勢豫领，就是防止出現(xiàn)兼容問題時對”黑盒框架“的束手無策抡柿。
2. 多頁面應(yīng)用
3. 單頁面應(yīng)用
前端MV*原理
- M: model表示數(shù)據(jù)模型，返回一個數(shù)據(jù)對象等恐，是展現(xiàn)給用戶的信息的一個抽象洲劣。
- V：view展示層，這里表示呈現(xiàn)給用戶的頁面课蔬。
- *： 這里通常有兩種囱稽，一種Controller，一種是VM（ViewModel）實際上是改進版的MVC二跋。
在我們常用的三大框架（vue战惊，react伟件，angluar）中都是通過虛擬dom來優(yōu)化直接使用瀏覽器dom操作api操作dom帶來的性能低下的問題脑豹，所以有兩層mv*漠嵌，
- data->virtual dom: 這里vue中的是data函數(shù)返回的數(shù)據(jù)對象督暂，react中是this.state渠抹，他們都是
- Virtual dom -> real dom：在虛擬dom與真實dom之間胳嘲，通過一些邏輯進行關(guān)聯(lián)圃伶，當(dāng)虛擬dom發(fā)生改變時會同步到真實dom上去
