沒有一種架構是可以滿足所有迭代的需求的
前言
架構並不是只限於技術選型
是架構設計作為軟體生命週期的一部分，並不是說開始的時候 設計完成後就會一成不變，軟體的生命週期包含了迭代、維護、重構等過程，架構設計亦是如此，所以說架構是需要變化的，目的就是適應當前情況的開發場景。
而架構產生的時間，必定是受到當時的約束條件，如人力、團隊技術積累、時間、業務定位等等需求。所以，當前架構可能並不能滿足未來的需求，我們要開放對待這個問題，只要當前的架構符合一定的設計原則，未來進行架構的演進就不是問題。
“架構”這個詞解釋也沒有一個明確的定義，每個層級，每個場景都有自己的解釋，所以到底什麼是架構呢？
軟體架構的定義
軟體架構（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
- 定期的技術交流分享
- 開發文件或程式碼註釋的生產
【小結】
本文在作為一個引子，先介紹了對於架構的一個認知，簡單的說明了在開發過程中我們需要怎樣的步驟去設計一個架構，以及架構設計中我們應該注意什麼，及架構設計者應該關注的層次，接下來的文章會更深入的介紹下前端架構
持續更新
- 【來聊一聊前端架構之二】前端架構的落地實施
- 【來聊一聊前端架構之三】構建符合當前專案的架構開發流程
- 【來聊一聊前端架構之四】前端腳手架在專案中的應用
- 【來聊一聊前端架構之五】前端架構中元件化的拆分
- 【來聊一聊前端架構之六】微前端架構在專案中應用
關注一波哦~