一、前言

昨天一個朋友問：我的工作只有vue、react，了解其他的好像沒有太大作用。其實不然，前端要考慮的內(nèi)容其實很多，不光是完成業(yè)務代碼。

我司的一個控制臺前端維護人數(shù)在20+，如果每個人都在一個項目中開發(fā)，那么每天就等著構(gòu)建了，不僅容易出錯，而且浪費時間，這對于線上項目是不可容忍的。

前端項目有大有小，這里假設我們面對的是一個相對復雜的中臺系統(tǒng)，那么要考慮的東西是很多的。下面我列舉了大部分，如果有缺失歡迎小伙伴補充。

下面列舉的內(nèi)容包含了必須的模塊，比如框架選型，接口調(diào)用，公共組件

有些是可選的模塊，比如各種規(guī)范約束，單元測試，多語言支持、模擬數(shù)據(jù)

還有一些是隨著系統(tǒng)的變大需要增加的，比如版本管理、灰度系統(tǒng)、自動構(gòu)建部署、頁面監(jiān)控，質(zhì)量測試，數(shù)據(jù)監(jiān)控等。

有一些是多人合作，提升效率的，比如前端CICD部署、微前端服務器

二、內(nèi)容總覽

- 1、基礎(chǔ)設施     - 1.1、文檔規(guī)范         - 1.1.1、接口文檔         - 1.1.2、開發(fā)文檔     - 1.2、代碼規(guī)范         - 1.2.1、Gitlab、git分支提交規(guī)范         - 1.2.2、tsconfig  (ts配置)         - 1.2.3、eslint 代碼質(zhì)量         - 1.2.4、pritter代碼格式化         - 1.2.5、css規(guī)范             - 1.2.5.1、重置瀏覽器樣式             - 1.2.5.2、兼容內(nèi)容         - 1.2.6、項目目錄規(guī)范         - 1.2.7、版本管理規(guī)范         - 1.2.8、接口規(guī)范         - 1.2.9、工具類函數(shù)和變量規(guī)范         - 1.2.10、注釋規(guī)范         - 1.2.11、項目環(huán)境配置（開發(fā)、生產(chǎn)、測試）         - 1.2.12、皮膚主題切換、語言切換     - 1.3、常用技術(shù)         - webpack         - mock         - 狀態(tài)管理     - 1.4、ui組件庫     - 1.5、cli腳手架 - 2、開發(fā)階段     - 2.1、技術(shù)選型         - 2.1.1、微前端框架         - 2.1.2、js庫選型         - 2.1.3、路由、導航規(guī)范     - 2.2、主要模塊         - 2.2.1、權(quán)限系統(tǒng)         - 2.2.2、公用組件管理         - 2.2.3、頁面框架     - 2.3、代碼質(zhì)量         - 2.3.1、單元測試         - 2.3.2、代碼質(zhì)量檢測         - 2.3.3、關(guān)鍵頁面性能分析     - 2.4、文件、圖片懶加載     - 2.5、其他         - 2.5.1、反向代理配置         - 2.5.2、模擬數(shù)據(jù)         - 2.5.3、引入路徑配置 - 3、部署階段     - 3.1、項目環(huán)境區(qū)分     - 3.2、自動化部署         - 3.3.1、shell腳本         - 3.3.2、CI/CD         - 3.3.3、代理、緩存配置、代碼壓縮     - 3.1、灰度系統(tǒng)     - 3.4、回退方案     - 3.5、容災方案     - 3.6、CDN - 4、監(jiān)控階段     - 4.1、前端js報錯監(jiān)控     - 4.2、頁面訪問統(tǒng)計系統(tǒng)     - 4.3、特殊頁面埋點 復制代碼

三、基礎(chǔ)設施

1.1、文檔規(guī)范

那句話咋說來著：研發(fā)最討厭的就是寫文檔，最喜歡的就是別人寫文檔

對于前后端分離開發(fā)來說，文檔是很重要的。

沒有文檔，大大增加了溝通成本，而且后期問題確認，維護都會很困難。

但后端又忙的沒有時間寫文檔，所以更多的時候最少可以通過自動化手段生成文檔，比如我這邊開發(fā)Golang服務、Node服務會使用Swagger生成文檔，對于工期緊張的項目，當然也可以通過Postman分享給前端，這樣對于雙方都可以減輕負擔。

開發(fā)文檔，可以幫助開發(fā)理清思路，記錄開發(fā)過程中困難，當然你的項目天天十萬火急，就當我沒說。

1.2、代碼管理

代碼管理，對公司而言，一般直接使用Gitlab就行了，搭建成本也很低，權(quán)限控制、自動發(fā)布等很完善了，當然一定要備份。

通過Gitlab，設置管理員權(quán)限，其他的角色可以分配可讀，可合并，可發(fā)布等權(quán)限。

為了代碼的干凈整潔，更好的維護，代碼格式化，代碼質(zhì)量，初始化樣式、目錄規(guī)范、接口規(guī)范、注釋規(guī)范、工具類函數(shù)規(guī)范等都是要提前確定好的，防止后面越寫越亂。

當然項目更新頻繁，還要考慮版本管理

項目有國外的用戶，需要配置語言切換。

換膚效果也是很多網(wǎng)站會需要的。

一個項目一般由一個人或多人開發(fā)，涉及到不同的功能，不同的人員，那么Git就是你必須要考慮的。涉及到多人管理，還會存在分支管理的問題，如果不同的人隨便搞，容易造成代碼混亂，所以在開發(fā)項目之前要制定Git代碼分支管理規(guī)范。

Git分支提交規(guī)范，如何區(qū)分提交內(nèi)容，是bug、新功能、優(yōu)化還是其他。如果定義好，對于之后的歷史查找會方便很多

1.3、其他

前端項目mock數(shù)據(jù)引入，方便前端調(diào)試和獨立開發(fā)。

如果公司的項目規(guī)模比較大，可能需要自建UI組件庫，配置CLI腳手架，去方便組員拉取代碼

很多人不寫代碼注釋，我也不喜歡寫，但注釋也是代碼的一部分，沒有好的注釋，一些業(yè)務要不了多久再看，就會一頭霧水，所以注釋能寫盡量寫，磨刀不誤砍柴工。

// 原則上空一格，單行注釋

/**/ 如果多行注釋可以使用這種方法，每個文件開頭可以使用的注釋格式有：

文件開頭一般寫上：

作者： 日期： 描述： 復制代碼

上面是一些建議的規(guī)范，當然優(yōu)秀的程序員要懶，可以直接使用插件，生成注釋，然后使用eslint去規(guī)范注釋的格式，這樣就可以保證項目中注釋的規(guī)范。

缺點是：增加了開發(fā)的成本，拖慢項目速度。如果你天天趕工期，還是把eslint禁了吧，寫完早點回家看看其他公司的機會。

四、開發(fā)階段

2.1、技術(shù)選型

現(xiàn)在我開發(fā)使用比較多的是，前后端分離的單頁應用，這里我們就以這種后臺為引，默認前后端分離。

考慮技術(shù)選型，其實Vue和React已經(jīng)幾乎能滿足所有的公司了，就算需要高度SEO，也有很多解決方案。

微前端，是必須要考慮的一個環(huán)節(jié)，如果項目劃分成了很多產(chǎn)品，每個產(chǎn)品都有對應的需求，想要所有的項目匯總在一個平臺，那么微前端絕對是不二的選擇，實現(xiàn)方案也比較多，可以選擇最合適的。

路由、導航都建議提取配置文件，可以讓項目更好的管理。

一個好的目錄結(jié)構(gòu)，應該是職責分明的。每個目錄做對應的事情，公用組件文件夾，工具函數(shù)文件、頁面路由文件、狀態(tài)管理文件等。

2.2、后臺的常見模塊

1、大多數(shù)后臺都需要權(quán)限管理，然后根據(jù)每個員工的角色不同，看到不同的內(nèi)容，那么就要求前端做好權(quán)限管理模塊的規(guī)劃，提取公用配置，進行多帶帶管理

2、公共組件，很多需求都是可以復用的，提高組件的復用性，可以減少代碼量，提高系統(tǒng)性能。

2.3、代碼質(zhì)量

本是同根生，相煎何太急。需求實現(xiàn)就行了，干啥這樣？ 但對于生產(chǎn)環(huán)境的項目來說，少一個bug就多一個客戶，所以為了保障線上的穩(wěn)定，這里有很多方案去解決。

上線前的單元測試，部署代碼分析系統(tǒng)來分析頁面的代碼質(zhì)量。對于關(guān)鍵的頁面還要進行針對的分析，查看加載速度，訪問數(shù)據(jù)等等

五、部署階段

3.1、打包部署

項目部署，可以很簡單，也可以很復雜，具體取決于自身需求。

如果簡單的可以通過shell腳本處理，復雜一點的可以通過CICD+K8S構(gòu)建。

3.2、打包不同的環(huán)境

我們的項目基本不會只部署生產(chǎn)環(huán)境，常常需要部署測試環(huán)境，那么我們常見的做法是通過配置環(huán)境變量來控制打包。

3.3、灰度系統(tǒng)

項目上線前要考慮，出現(xiàn)問題怎么及時挽救，這里我們就要考慮，要怎么實現(xiàn)灰度方案，在全面部署前，先灰度一部分用戶，就像手機軟件常常要求你體驗搶鮮版，確保基本沒問題，在正式部署。

3.4、版本回退

一個項目在發(fā)布出現(xiàn)問題后，必須要有回退的能力。這樣當遇到問題時，可以及時的進行代碼的回滾操作，保證線上穩(wěn)定。

3.5、容災

自然災害誰也料不到，如果單點部署我們的業(yè)務，一旦云服務商一個機房出現(xiàn)問題或虛機宕機，必然影響到業(yè)務，所以要考慮負載均衡，多節(jié)點部署。

3.6、CDN

大訪問量的網(wǎng)站，如果廣州的客戶請求部署在北京機房的服務，那么打開速度必要會慢，在廣州買臺服務器卻沒有必要，這時候選擇CDN，通過一個個節(jié)點，減輕服務器壓力，讓用戶打開速度更快。

六、監(jiān)控階段

想像一下，如果你打開一個網(wǎng)站，前端報錯，這時候頁面卡死，作為開發(fā)其實是看不到的，那么就無法解決這個問題，可能用戶就直接關(guān)了這個頁面，不再訪問了。這樣肯定是不行的，我們可以通過監(jiān)控系統(tǒng)，去收集這些錯誤，及時解決這些bug，比如開源軟件sentry

用戶是通過什么渠道進入你的頁面的，你的頁面每天的訪問量是多少？我們可以通過統(tǒng)計系統(tǒng)分析日志請求，來匯總這些信息，常見的有百度統(tǒng)計。

對于一些重要的頁面，也需要增加標記，記錄訪問用戶，一旦惡意請求，可以及時屏蔽，比如goaccess分析nginx日志。

七、最后

當然這其中很多都是一些規(guī)范問題，對于小項目來說，考慮的不多； 對于大項目來說，很多內(nèi)容也都是只需要一次配置，也有一些方案是根據(jù)項目發(fā)展來配置的，比如灰度系統(tǒng)的實現(xiàn)方案。

以上是我現(xiàn)在可以考慮到的方面，不足的方面希望各位可以補充下。