【來聊一聊前端架構之一】前端架構認知

沒有一種架構是能夠知足全部迭代的需求的

前言

架構並非只限於技術選型

是架構設計做爲軟件生命週期的一部分，並非說開始的時候 設計完成後就會一成不變，軟件的生命週期包含了迭代、維護、重構等過程，架構設計亦是如此，因此說架構是須要變化的，目的就是適應當前狀況的開發場景。

而架構產生的時間，一定是受到當時的約束條件，如人力、團隊技術積累、時間、業務定位等等需求。因此，當前架構可能並不能知足將來的需求，咱們要開放對待這個問題，只要當前的架構符合必定的設計原則，將來進行架構的演進就不是問題。

「架構」這個詞解釋也沒有一個明確的定義，每一個層級，每一個場景都有本身的解釋，因此到底什麼是架構呢？

軟件架構的定義

軟件架構（software architecture），是一系列相關的抽象模式，用於指導大型軟件系統各個方面的設計。
-摘自百度百科

其實軟件開發和蓋一棟大樓同樣，都須要規劃、設計、實施等一系列的階段，最開始設計建築圖紙，主體架構，還要考慮綠化、材料、安全等因素。通過一系列的決策，纔有一套成熟的建築施工方案，按照規範建造，才能保證質量和速度。

而開發一個軟件或前端工程也是一個「建築」的過程,咱們要經過業務來定位系統間的關係，討論技術棧和框架的選用，根據當前團隊的技術水平進行技術的選型、考慮各個模塊間的界限和交互，上線部署策略，問題回滾策略等一系列的決策才能設計出符合當前狀況的技術架構。

前端開發過程當中須要怎樣的架構

大致來看基本要求點以下：

• 符合當前的業務定位
• 前端架構必須具備可實施性
• 必須匹配當前技術儲備
• 有足夠的人力資源去完成
• 具備可伸縮、可擴展性

【因地制宜】應該是開始設計架構的基本準則，每套架構的產生都有他的外界因素影響，因此，各個公司，各個團隊之間的架構不能照搬，若是強制搬過來，可能會拔苗助長，就像你那 alibaba 的技術架構去搬到 初創 公司，那是根本行不通的，人員，資源不匹配，是沒辦法去實施架構的。

所以咱們在項目前端開發的生命週期中指望的架構應該具備哪些要點呢？

• 準確的業務定位，業務多是影響架構的主要因素之一，因此咱們要找準業務上的定位
• 明確與其餘系統之間的關係，肯定與其餘系統的層次關係，相互間的通信依賴等
• 設計好系統內子模塊之間的關係，如A業務模塊須要與B模塊交互，該採起怎樣的方式
• 基礎模塊明確，項目中，一定含有基礎模塊去提供一些公用的方法，數據去提供給各個子模塊
• 組件規劃，這就是再細一層的規劃了，制定組件的交互方式，開發範式
• 開發規範和上線流程，用於指導開發中的過程

架構設計 setp

設計須要進行一系列的技術及非技術的相關工做

• 收集利益相關者的需求，產品經理、業務人員、項目負責人等
• 與相應技術人員進行討論，肯定架構上的潛在限制和要求
• 尋找可行性的技術方案
• 細化技術方案細節，肯定一些功能列表中的技術可行性
• 肯定風險點
• 與技術人員反覆討論，集合你們意見
• 對技術方案進行demo的概念驗證
• 結合當前業務，細化架構的部分實施細節
• 進行排期

架構設計原則

不一樣的架構師可能會有不一樣的觀點，可是能被人大多數架構師認同的有一下三點

• 很少也很多：不作多餘的設計，也不缺乏核心部分

設計過少則爲設計不足，會使一個框架的伸縮性和擴展性不強，不能靈活的面對即將產生的業務需求的迭代。
設計過分也不必定是件好事，針對將來的技術框架或者需求的變動，咱們不能保證目前的架構就必定能兼容這些變化，過分設計反而會讓咱們一會的架構重構產生不少無用的開發變動，增長成本反而得不到相應的輸出價值。

• 演進式：不斷的演進以架構適應當前的環境

適應環境可以生存下來的物種，並非那些最強的，也不是最聰明的，而是那些對變化作出快速反映的。 -達爾文

演進事架構是指在開發過程當中，預先設計好重要的部分如系統模塊通訊，功能模塊劃分，具體組件顆粒度等，而後在編碼過程當中，再進行細顆粒度的劃分，遇到不適合的地方，進行快速的反應，找到最優解，最理想的狀態是，20%的計劃，80%的演進設計

• 持續性：長期的架構的改進

持續性和演進式有必定的共同性，演進式的目標是在開發過程當中進行架構的細化，持續性則指在迭代過程當中進行框架的進階，在迭代過程當中，不免會出現架構不符合當前情況的狀況，咱們要靈活應對，進行持續性的優化，這樣才能在迭代開發過程當中，作到最優框架的目的

【延遲決策】有時候「拖延症」也並不必定是壞處，哈哈，開個玩笑，在咱們設計架構的時候，會經歷一系列的方向決策，可是一個框架的發展並非老是一路順風，當遇到演進方向決策的時候，沒有找到最優解，咱們能夠進行延遲決策，等等，也許就會有答案，這樣也許會比當時匆忙作出的決定要更符合預期。

前端架構設計的層次

不一樣階段構成架構的因素是不一樣的，基於這個思路，架構設計能夠分爲四個層級

1.系統級

對於其餘業務系統，咱們該如何設計之間的通訊、協做、交互。好比A系統承載了內容庫模塊，B系統須要用其中的選擇內容組件，咱們設計了一套csi。去託管通訊

• 對於先後端的服務通訊方式。ws or http，鑑權，config記錄等
• 對於報錯收集處理的基礎信息建設
• 是否採用微前端等架構

2.應用級

應用級是指多個子應用直接的關係設計，多是子應用，子模塊，lib包、共享模塊等，也就是架構設計的進一步細化

• 腳手架的設計，能夠規範應用的基礎，有利於快速的構建子模塊或者子應用，加入一些格式化插件，能夠有效的防止一些不符合要求的代碼上傳到遠程倉庫
• lib包設計，能夠把一些公用的，細顆粒度，重複利用性高的做爲一個lib包抽取
• 組件系統模板，基礎組件設計好模板，有利於提升開發效率

3.模塊級

模塊級是深刻到子應用的級別的層次，顆粒度更加細化，包含一些設計模式和UI層面的規定，好比，單項仍是雙向數據流，採用的UI模板，公共css等

4.代碼級

代碼級的層級用於規範開發人員的代碼，提升代碼質量，此層次要作的工做有：

• 初期的開發指導文檔
• 開發過程當中的 codeReview
• 按期的技術交流分享
• 開發文檔或代碼註釋的生產

【小結】
本文在做爲一個引子，先介紹了對於架構的一個認知，簡單的說明了在開發過程當中咱們須要怎樣的步驟去設計一個架構，以及架構設計中咱們應該注意什麼，及架構設計者應該關注的層次，接下來的文章會更深刻的介紹下前端架構

持續更新

• 【來聊一聊前端架構之二】前端架構的落地實施
• 【來聊一聊前端架構之三】構建符合當前項目的架構開發流程
• 【來聊一聊前端架構之四】前端腳手架在項目中的應用
• 【來聊一聊前端架構之五】前端架構中組件化的拆分
• 【來聊一聊前端架構之六】微前端架構在項目中應用

關注一波哦~