一、前言

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

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

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

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

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

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

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

二、內(nèi)容總覽

- 1、基礎(chǔ)設(shè)施     - 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、項(xiàng)目目錄規(guī)范         - 1.2.7、版本管理規(guī)范         - 1.2.8、接口規(guī)范         - 1.2.9、工具類函數(shù)和變量規(guī)范         - 1.2.10、注釋規(guī)范         - 1.2.11、項(xiàng)目環(huán)境配置（開發(fā)、生產(chǎn)、測(cè)試）         - 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、路由、導(dǎo)航規(guī)范     - 2.2、主要模塊         - 2.2.1、權(quán)限系統(tǒng)         - 2.2.2、公用組件管理         - 2.2.3、頁面框架     - 2.3、代碼質(zhì)量         - 2.3.1、單元測(cè)試         - 2.3.2、代碼質(zhì)量檢測(cè)         - 2.3.3、關(guān)鍵頁面性能分析     - 2.4、文件、圖片懶加載     - 2.5、其他         - 2.5.1、反向代理配置         - 2.5.2、模擬數(shù)據(jù)         - 2.5.3、引入路徑配置 - 3、部署階段     - 3.1、項(xiàng)目環(huán)境區(qū)分     - 3.2、自動(dòng)化部署         - 3.3.1、shell腳本         - 3.3.2、CI/CD         - 3.3.3、代理、緩存配置、代碼壓縮     - 3.1、灰度系統(tǒng)     - 3.4、回退方案     - 3.5、容災(zāi)方案     - 3.6、CDN - 4、監(jiān)控階段     - 4.1、前端js報(bào)錯(cuò)監(jiān)控     - 4.2、頁面訪問統(tǒng)計(jì)系統(tǒng)     - 4.3、特殊頁面埋點(diǎn) 復(fù)制代碼

三、基礎(chǔ)設(shè)施

1.1、文檔規(guī)范

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

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

沒有文檔，大大增加了溝通成本，而且后期問題確認(rèn)，維護(hù)都會(huì)很困難。

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

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

1.2、代碼管理

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

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

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

當(dāng)然項(xiàng)目更新頻繁，還要考慮版本管理

項(xiàng)目有國(guó)外的用戶，需要配置語言切換。

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

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

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

1.3、其他

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

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

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

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

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

文件開頭一般寫上：

作者： 日期： 描述： 復(fù)制代碼

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

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

四、開發(fā)階段

2.1、技術(shù)選型

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

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

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

路由、導(dǎo)航都建議提取配置文件，可以讓項(xiàng)目更好的管理。

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

2.2、后臺(tái)的常見模塊

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

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

2.3、代碼質(zhì)量

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

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

五、部署階段

3.1、打包部署

項(xiàng)目部署，可以很簡(jiǎn)單，也可以很復(fù)雜，具體取決于自身需求。

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

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

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

3.3、灰度系統(tǒng)

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

3.4、版本回退

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

3.5、容災(zāi)

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

3.6、CDN

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

六、監(jiān)控階段

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

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

對(duì)于一些重要的頁面，也需要增加標(biāo)記，記錄訪問用戶，一旦惡意請(qǐng)求，可以及時(shí)屏蔽，比如goaccess分析nginx日志。

七、最后

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

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