概述
這幾天我讀了 前端架構：從入門到微前端，感覺收獲挺大的，把讀書筆記發出來，供以后開發時參考，相信對其他人也有用。
讀書筆記
1.對於只使用后端 API 的前端來看，后端看上去像只做 CRUD。然而，后端並不像看上去那么簡單。從架構層面考慮，后端是要事先高並發和高可用的。在多數情況下，數據庫是后端最大的瓶頸，存儲的時候要考慮原子性、一致性、隔離性和持久性，使用的時候要考慮通過分表、存儲、主從同步來提高性能和並發量，在這個過程中還要考慮備份、遷移、查詢速度、效率等問題。此外，在代碼實現上還有一系列的復雜問題：使用消息隊列來解耦依賴，使用微服務來拆分單體應用。
2.規范、原則、模式、架構，是我們在前端架構中需要關注的內容。
3.架構的步驟如下：
1.收集利益相關者的需求
2.與相應的技術人員討論，了解架構上的潛在限制
3.尋找潛在的可行性技術方案
4.整理出功能列表中的功能需求和跨功能需求
5.找出會嚴重影響開發的風險點
6.和技術委員會、利益相關者反復確認方案
7.對架構設計進行概念證明
8.細化架構的部分實施細節
9.結合技術和業務，進行需求排期
（在這個過程中，最重要的還是收集相關的架構需求）
4.在設計架構的過程中，各個組織、開發人員、架構師都擁有自己的關注點。在大部分的項目中，都會擁有相似的一些關注點，也因此它們會來自於其他項目的經驗。不同的項目因為自身的需求，對於各種特性的優先級考慮往往是不一樣的。有的項目認為安全更重要，由安全帶來的用戶體驗下降的問題是可以允許的；而有的項目認為用戶體驗更重要，也便能忍受其影響到的其他特性。
5.在開發人員和運維人員部門分離的組織里，往往會在內部限制某些語言，如選定 Java 等語言，限制其他語言的使用。如果選定的是其他語言，如 Javascript + Node.js，那么運維人員便難以維護，需要進行培訓或者招聘新的運維人員。
6.在日常的開發中，常見的架構風格有：1.分層風格。2.MVC架構風格。3.發布-訂閱風格。4.管理和過濾器。
7.MVC架構風格在涉及圖形用戶界面時，往往都有它的身影，如前端應用、移動端應用等。
8.發布-訂閱風格帶來的最大好處是，代碼上的解耦。
9.架構的設計原則：1.不多也不少。2.演進式。3.持續性。
10.采用敏捷模式是為了應對用戶需求的不斷變化，而需求的變化，則可能會和早期確認的方向不一致，與最初設計的架構不匹配。
11.瀑布模式采用的是完全計划式設計，即在編碼前，由頂層至底層進行的一系列架構設計，包含了各個模塊、服務、函數和接口。而演進式架構，則是預先設計好重要的部分如模塊功能划分、領域划分等粗粒度，隨后在編碼的過程中，再進行函數和接口的設計和實現。
12.一旦前端應用需要從后端獲取數據，就意味着前端應用在運行時是動態地渲染內容的，這便是 Model-UI 層解耦。
13.隨着前端單頁面應用的流行，前端進入了一個新的時代，要考慮的內容也越來越多：1.api管理。2.大前端。3.組件化。
14.MVC 滿足不了開發人員的需求，於是采用了組件化架構。而組件化 + MV*也無法應對大型的前端應用，微前端便又出現在我們的面前，它解決了以下問題：1.跨框架。2.應用拆分。3.遺留系統遷移。
15.前后端分離架構其實是一個籠統的概念，它是指前后端分離如何實施的技術決策。它包含了一系列的決策、用戶鑒權、API接口管理與設計、API 文檔管理、Mock Server使用、BFF（服務於前端的后端）、是否需要服務端渲染等。
16.應用級架構有：1.腳手架。2.模式庫。3.設計系統。
17.代碼級的規范與原則包含下面內容：1.開發流程。2.代碼質量及改善。3.規范而非默契。
18.優秀的軟件開發人員，帶有強烈的工匠精神，當遇到問題時，便會想着如何去解決它。
19.技術負責人日常要做的事情有以下幾方面：1.適當地平衡業務的進度與技術方案。2.解決重要、復雜的技術問題。3.幫助團隊的其他成員成長。4.從全局考慮整個項目的技術和業務問題。
20.在項目實施的過程中，有三個要素：1.保證項目在開發過程中的質量。2.提升人員的能力。3.確保功能和應用上線。
21.概念驗證（PoC）是對某些想法的一個較短而不完整的實現，以證明其可行性。
22.當我們開始一個項目的時候，進入的是迭代1的開發，那么迭代0呢？我們可以將其視為在所有迭代之前的准備工作。
23.為了有針對性地規范代碼，並幫助其他成員了解代碼，一個相應的舉措便是編寫相應的項目示例代碼。
24.先進的架構，並不一定會為業務帶來價值；先進的技術，也並不一定會為業務帶來價值。
25.整個分享結束，掌握得最好的人，便是那個做技術分享的人。
26.不論怎樣，程序員作為一個“匠人”，總得有點“追求”，要不斷地提高自己的水平。
27.1.0時期，迭代0就是選定一個前端框架。2.0時期，迭代0應該是選定前端框架 + 完整的構建腳本和構建系統。3.0時期，迭代0應該是選定前端框架 + 完整的構建腳本和構建系統 + 流程規范化。
28.為了降低開發成本，我們還需要擁有一些前端應用腳手架、自己的開發工具或者協作工具。於是，工作的重心便從業務轉向了構建工具。
29.常規代碼檢視，即團隊成員聚在一起，聽其他成員講述自己最近（通常是今天）寫的代碼。一個完整的代碼檢視是從講述相關的業務功能、技術功能開始的，而非打開IDE直接講代碼的實現；阻塞式代碼檢視，通常是提交一個 pull request，即要求其他人把代碼拉倒主分支，這就要求項目中的其他開發者來幫助我們檢視代碼。
30.在 Node.js 領域里，可以使用 cnpmjs 來搭建自己的私有化包服務器。
31.本地的依賴包是指：把應用的依賴放在本地，它通過包管理工具來支持 file 協議並引入依賴，即在 package.json 中通過 "aofe:" "file:aofe"的形式來引入依賴。
32.盡管前端部署很簡單，還是適當的考慮“回滾機制、藍綠部署、灰度發布”等因素。並在應用部署后，使用 UI 自動化測試來測試部分功能是否正常，以及測試對應的后端服務連接。
33.功能開關是一種強大的技術，允許團隊在不更改代碼的情況下修改系統行為。
34.在學習編程的初級階段里，經常會掉入一個陷阱：一旦學會一個新的框架，就會在我們的大部分項目中使用這個框架。即所謂的“錘子定律”：
我認為，假設你所擁有的工具只有一個錘子時，你把所有的事物當做釘子來對待時很有吸引力的。
35.對於面向 Google 的網站而言，它可以提供更好的 Javascript 渲染支持，可以直接抓取 Javascript 渲染的應用。然而，對於國內的開發者而言，多數時候我們要面對百度、搜狗等搜索引擎，它們對 Javascript 渲染頁面的支持並不是很好。
36.為了提供更好的用戶體驗，一些代碼邏輯會重復地在前后端出現，比如表單的校驗。對於一個長的或者復雜的表單，在用戶填寫的過程中，應該實時提示用戶哪些字段出錯。而不是在用戶提交表單后才告訴用戶哪里有錯。
37.多頁面應用往往是一些輕量級的前端應用，多數時候會被划定為“前端頁面”——往往只需要編寫頁面樣式，和編寫一些 Javascript 就能完成工作。常見的這類應用有：
1.門戶類、資訊類、數據展示類應用
2.弱交互應用
3.面向資源受限的設備應用
38.我們選擇 MVC 框架，多數是因為我們需要其中一些特性，比如：
1.模板引擎，動態生成、創建頁面
2.雙向綁定，實時修改數據
3.前端路由，路由變化映射到對應的邏輯上
...
39.基於 Javascript 的模板引擎的表現形式是，將模板轉移為 Javascript，在執行的過程中，再動態更新所需要的 DOM 節點。它和基於字符串的模板引擎的區別主要在於第三點，是否全局替換 DOM 節點。
40.雙向綁定是指：
1.視圖的變化能實時地讓數據模型變化
2.當數據發生變化時，對應的視圖上的值也發生變化，此時需要更新視圖的值
41.路由的 hash 具有以下一些特點：
1.hash值得概念不會導致頁面重新加載
2.hash值由瀏覽器控制，不會發送到服務器端
3.hash值的改變會記錄在瀏覽器的訪問歷史中，因此可以在瀏覽器中前進和后退
42.前端MV*框架的原理就是通過觀察和訂閱來進行聯動操作，以自動觸發各種邏輯函數。
43.框架選型的考慮因素：
1.團隊成員能否快速掌握該框架？
2.框架的生態是否豐富？是否擁有我們所需要的功能組件？
3.不同的框架對於不同瀏覽器的支持程度如何？
4.框架的后期維護成本和難度怎樣？
5.能否以最小的代價遷移現有的應用？
44.react和vue相對於 angular 來說是小而美的框架，這些框架和 angular 相比的主要問題是：維護成本太高。
45.除了在編寫應用時不需要對 DOM 進行直接操作、提高了應用的性能，React還有一個重要的思想即組件化。
46.創建組件庫的步驟如下：
1.尋找一個現成的組件庫。
2.構建出組件庫的基礎設施。從步驟1的組件庫中刪除所有的組件，修改項目名等。
3.編寫一兩個測試組件，引入項目中進行測試
4.持續不斷地更新組件庫
47.組件的發展過程如下：
1.風格指南，早起側重視覺，對設計的文字、顏色、LOGO、ICON等設計做出規范，產出物一般稱為Guideline，Guideline通常是UI規范
2.模式庫，即UI組件庫，側重於前端開發，產出物一般稱為組件庫UI框架，比如Bootstrap庫
3.設計系統，結合了風格指南和模式庫，並附加了一些業務特別元素，進一步完善了組件化到頁面模板相關的內容
48.基礎的UI組件如何擺放成一個頁面，它們擺放的位置和相互關系就是一個UI系統特有的模式
49.在Web應用中，通常對顏色有如下區分：
1.主題色，又稱為品牌色，用於體現產品的特性及宣傳時使用。
2.功能色，用來展示數據和狀態，以及提醒用戶
3.中性色，用於常規的頁面顯示和過渡，通常是淺色和深色的變種，如白色和灰色
（在一些設計系統中，會提供相應的顏色模板）
50.在早起的Windows系統里，某些字沒有13px大小的字體，因而多數采用的是偶數。這種奇怪的習慣也被保留到今天。
51.Grid設計有很多別稱：網格設計系統等。它其實是使用百分比進行布局的。
52.Grid布局可以輕松應對左右布局的頁面，但是對於上下布局的頁面來說，Grid布局基本很難實現，所以有了 flex 布局。Flex 布局也叫做彈性盒子布局。
53.組件的質量和數量是通過兩種方式來提升的：需求、新的Bug。
54.組件的二次封裝不外乎兩種模式：
1.中介者模式。用一個中介者來封裝一系列的對象交互，它提供了與原有組件一致的屬性、輸入和輸出。
2.裝飾者模式。在不改變原類文件及不使用繼承的情況下，動態地將責任附加到對象上，從而實現動態拓展一個對象的功能，如果某個組件的屬性、輸入、輸出不符合API規范，那么我們就創建一個新的接口，來保證它符合規范。
55.風格指南通過創建統一的風格、規范的樣式、合適的元素大小來規范化設計；模式庫通過創建統一的組件、組合的組件命名、統一的使用方式來規范化組件的使用。但是這些模式、規范等，並沒有明確地標明出來，在不同的設計人員的心里，可能有不同的規則、原則，而沒有統一。所以就催生出了設計系統。
56.設計系統包含如下指南：
1.動作
2.無障礙
3.內容原則
4.信息架構
57.設計系統分為設計原則和設計模式。設計原則比如：親密性、對齊、對比、重復、直截了當、簡化交互、足不出戶、提供邀請、巧用過渡、即時反映。設計模式比如：色彩、數據錄入、數據展示、空狀態、布局、加載、本地化、字體、搜索、導航、消息、標記和風格等。
58.出於簡潔考慮，有的應用的 header 會顯得非常簡單，隱藏一些不常用的功能。而有的設計，則會將 header 設計成帶動畫和過渡的，當我們打開頁面的時候，看到的是完整的 header；而當我們往下滾動一段距離的時候，看到的是簡潔的、修改的 header。
59.一說到前后端分離，人們最大的痛楚莫過於對 API 的管理和維護。
60.作為一個專業的前端開發人員，考慮后端接口對於前端的合理性，也是日常工作的一部分。
61.與普通的Mock Server相比，DSL（領域特定語言）形式的 Mock Server 的最大特點是用配置代替代碼。
62.BFF 的使用場景如下：
1.應對多端應用
2.聚合后端微服務
3.代理第三方API
4.遺留系統的微服務化改造
63.API Gateway 與 BFF 最大的區別在於，API Gateway 只擁有一個 API 入口。
64.GraphQL 讓前端能夠編寫查詢語句，獲取自己需要的數據。
65.如果業務一直在變動，或者需要對外提供 API，選擇 GraphQL 更合適。
66.康威定律：設計系統的組織，其產生的設計和架構等價於組織間的溝通結構。
67.微前端架構可以采用以下幾種方式進行：
1.路由分發式。通過 HTTP 的反向代理功能，將請求路由到對應的應用上。
2.前端微服務化。在不同的框架之上設計通信和加載機制，以在一個頁面內加載對應的應用。
3.微應用。通過軟件功能的方式，在部署構建環境中，把多個獨立的應用組合成一個單體應用。
4.微件化。開發一個新的構建系統，將部分業務功能構建成一個獨立的 chunk 代碼，使用時只需要遠程加載即可。
5.前端容器化。將 iframe 作為容器來容納其他前端應用。
6.應用組件化。借助於 Web Components 技術，來構建跨框架的前端應用。
68.在微前端設計初期，構建基礎設施要做如下幾件事情：
1.組件與模式庫
2.應用通信機制
3.數據共享機制
4.專用的構建系統(可選)
69.普通的父子級通信可以做到以下幾方面：
1.通過PostMessage在父子窗口之間進行通信。
2.通過parent.window尋找父窗口，再發出全局的自定義事件
3.當其他應用加載時，將消息發送給父窗口，由父窗口發出自定義事件
4.當其他應用未加載時，先將消息傳遞給父窗口，再由父窗口進行儲存，提供一個獲取通信的機制。
70.常見的數據交互方式，有以下幾種：
1.URI 參數傳遞
2.使用 LocalStorage 共享數據
3.其他客戶端儲存，如 IndexDB、Web SQL 等
4.服務端儲存客戶端狀態，可以采用 JSON 格式儲存
71.設計的過程就是識別、度量模塊內的聯系，再將相關的行為聚集在一起，把不相關的行為放在別處。在實踐的過程中，主要基於單一職責和關注點分離兩個原則來實現。
72.在開發能力完備的情況下，架構走向不合理的原因是 KPI，由 KPI 導向的系統架構設計，必然會出現一定的不合理性。從這種角度看，架構是不是最好的不重要，重要的是大家都滿意——只有領導滿意，才可以多漲工資；只有被團隊采用，才可以向外宣傳，吸引新成員。
73.業務層的耦合直接影響了技術上的耦合，這個困境導致了技術架構在不斷變化。所以我們需要一個專家，這里的專家並非單純指技術方面的專家，而是技術專家 + 業務專家，他可以是一個懂業務的技術專家，或者是一個懂技術的業務專家。
74.微前端的路由分發難點在於：原先我們只是將路由分發到應用的組件執行，現在則需要根據路由來找到對應的應用，再由應用分發到對應的組件上。
75.iframe 的通信機制：直接在每個應用中創建 postMessage 事件並監聽，並不是一個友好的事情。其本身對於應用的侵入性太強，因此通過 iframeEl.contentWindow 去獲取 iframe 元素的 window 對象是一個更簡化的做法。
76.微應用化是指，在開發時應用都是以單一、微小應用的形式存在的，而在運行時則通過構建系統合並這些應用，組合成一個新的應用。它有2個缺點：1.所有應用的依賴需要統一。2.高度依賴於持續集成（必須需要每30分鍾構建一次）。
77.微服務的基座一般包含以下功能：
1.管理其他子應用
2.負責應用間的通信
3.設計路由的響應機制
4.支持嵌入常規及iframe模式
78.微件化是指，每個業務團隊編寫自己的業務代碼，並將編譯好的代碼部署到指定的服務器上。
79.web components 主要由如下四項技術組成：
1.Custom Elements(自定義元素)，允許開發者創建自定義元素
2.shadow dom(影子DOM)
3.html templates(html模板)
4.html imports，用於引入自定義組件
80.在編寫應用的過程中，我們學會如何使用某個框架、語言，在演進架構的過程中，我們學會如何去做應用。前者是一個開發人員的基線，后者則是一個開發人員成長的機會。對於前端開發人員來說，我們會更關注架構的成長，因為它會為自己帶來更多的成長。
81.一般的版號格式是：主版本號、次版本號、修訂號，其版本號遞增的規則如下：
1.主版本號：當你做了不兼容的 API 修改
2.次版本號：當你做了向下兼容的功能性新增
3.修訂號：當你做了向下兼容的問題修正
82.在復雜的前端處理邏輯中，采用 reactive.js 或者 rambda 來解決問題。
83.當我們要解決大量的浮點計算的問題時，需要引入如 bignumber.js 這樣的庫。
84.怎樣的重寫才能帶來業務價值：
1.更少功能完成時間
2.更好的用戶體驗
3.提升應用的性能
85.以下項目需要重寫：
1.過時的依賴或技術
2.出現表達力更好的技術
3.舊代碼無法維護
86.如何讓一個我們覺得“爛”的系統慢慢變好？舊的系統給我們帶來一系列深入的思考，我們會思考平時哪里做的不好，應該怎么做才能讓系統變得更好？如果能不斷地在新舊系統之間切換，那么我們就能理解好的架構的意思，好的設計的初衷。並且，只有經歷過遺留系統，才能讓自己真正地成長。