！！！高能預警，長文，我都不知道多少字。

背景

我嘛，雖然不是出身bat，寫了三年多業務代碼，18年開始帶團隊至今，從toB的pc、管理臺、小程序、微信公眾號、app、活動、服務端，都有涉獵。當然公司小，我這種人就是跟著公司一點一點成長起來的，沒有前人栽樹，只能自己動手，天資不夠，只能靠肝。大概在17年底的時候，帶我的老大（老大呀，看到文章別diss我）離職了，我就這樣被趕鴨子上架（其實我的心態是崩潰的，沒玩過呀）做了起了前端負責人，后來經歷老員工離職，招聘，新員工入職，公司明確業務，業務量爆發，前端業務線暴漲之后，有幸做一些簡單的基礎服務，這套東西能讓3個前端，應付10條以上業務線，我可以自豪的說1年多以來，單季度，bug數<=1、技術問題延期<=0。經歷了百來個活動頁，3個移動端，8個管理臺，1個pc商城，2個小程序，上千萬的pv，各種瞎逼情況慢慢磨練出來的。歷時至今，1年半的時間，我算是做出了一些，我想做的事情。

目前全公司涉及前端業務線

• mobile 3條

  • 商城性質
  • 管理性質
  • 活動性質

• 小程序 2條

  • 商城性質
  • 備用小程序

• pc端 9條

  • 對外商城性質
  • 對外數據管理臺
  • 內部運營管理臺
  • 內部自營管理臺
  • 內部財務管理臺
  • 半內半外的招商管理臺
  • 對外第三方商家管理臺
  • 舊，運營管理臺
  • 舊，招商管理臺

基礎服務

技術棧選擇

• 移動端

技術棧選擇Vue全家桶，從我的視角來說，移動端的交互不會特別復雜，最多sku選擇、地址、動畫，而且這一塊大部分都是純面向用戶的需求，很難做業務收束，而且很難解耦。基于我的思考，我就想到vue了，輕便、簡單、插件豐富，vue滿足我的所有需求。說簡單點，我一個業務new個Vue對象，寫一堆配置/方法就搞定了。活動的話，我選擇了nuxt，活動這種輕便的東西，我靜態化就好了。

• pc端

技術棧選擇React全家桶，從我的視角來說，pc端我面向的都是管理臺需求居多，涉及的交互可能會相對而言復雜，會有拖拽、富文本、頁面編輯、圖表等等交互出現，這個時候React這種以Component為基本單位的庫對于這類業務來說，就很舒服了，解耦不要太爽。

• 小程序用原生

我這邊就只有微信小程序，原生確實夠用了，而且原生小程序框架也越來越強大，等需要擴展渠道時，我再選擇Taro、mpVue等東西。

• npm

請搭建私有的npm，可以做到公共方法的收集，集中化處理。

• mock平臺

搭建0業務入侵的mock平臺。

• nginx管理

集中管理前端的nginx。

• git倉庫

gitlab天下第一。

• 項目模版

將vue、react根據業務，制作為基礎模版，以后展開新業務直接copy即可。

• 持續發布

jekins天下第一

• eslint

服務器初始化

• 腳本

總結：其實最有爭議的應該是技術棧的選擇了，為啥要既有vue、又有react、還有小程序、nuxt，不好意思，我覺得在不同場景下，使用不同的庫是合理的。并且作為一個程序員，你的學習能力跟不上，那你還是自己走吧。我還沒上typeScript、Rx.js呢。還有就是招聘問題，不好意思，當面試者問我公司前端技術棧時，大部分都躍躍欲試。成本吧，反正不貴。

具體實現

這里我只對，nginx管理、私有的npm、mock平臺、項目模版、服務器初始化，做詳細具體解釋。其余的提一點，就不做解釋了，因為jekins就是配置，這個業務性太強，eslint沒啥講的，git倉庫也沒啥講的，小程序原生、pc端、移動端這都是純業務的東西，也沒啥講的。

nginx管理

新建nginxConfig文件夾，目錄結構如下。

nginxConfig |----- build.sh # 腳本 |----- server.develop.xxxx.com.conf # 對外服務的nginx配置 |----- server.develop.xxxx.com.ssl.conf # 對外服務的nginx，https配置 |----- server.test.xxxx.com.conf # 測試服務器的nginx配置，涵蓋所有業務 |----- server.test.xxxx.com.ssl.conf # 測試服務器的nginx，https配置，涵蓋所有業務 |----- server.admin.xxxx.com.conf # 管理臺的nginx配置 |----- server.admin.xxxx.com.conf.ssl.conf # 管理臺的nginx，https配置 復制代碼

請善用腳本，其實我只需要將nginx，發布到服務器上面根據不同服務器，cp不同nginx配置，然后relaod即可。nginx重啟失敗我倒是沒有碰過，我用這套已經部署了n臺活動服務器、n臺管理臺服務器。當然，寫nginx時請在測試服務器謹慎測試。我一般是凌晨3、4點去折騰的，誰叫我肝好呢。

附上腳本代碼

# /bin/bash echo "請選擇你要替換的nginx" echo "1) 替換xxxx，nginx" echo "2) 替換xxxx，https的nginx" echo "3) 替換xxxx，的nginx" echo "4) 替換xxxx，https的nginx" echo "5) 替換xxxx，的nginx" echo "6) 替換xxxx，https的nginx"read number case $number in 1)echo "替換xxxx，http的nginx"\cp server.admin.xxxx.com.conf /etc/nginx/conf.d/service nginx -reload ;; 2)echo "替換xxxx，https的nginx"\cp server.admin.xxxx.com.ssl.conf /etc/nginx/conf.d/service nginx -reload ;; 3)echo "替換xxxx的nginx"\cp server.test.xxxx.com.conf /etc/nginx/conf.d/service nginx -reload ;; 4)echo "替換xxxx，https的nginx"\cp server.test.xxxx.com.ssl.conf /etc/nginx/conf.d/service nginx -reload ;; 5)echo "替換xxxx的nginx"\cp server.develop.xxxx.com.conf /etc/nginx/conf.d/service nginx -reload ;; 6)echo "替換xxxx，https的nginx"\cp server.develop.xxxx.com.ssl.conf /etc/nginx/conf.d/service nginx -reload ;; esac 復制代碼

告訴你通過腳本編寫好處，別看我現在雖然是手動到服務器上去git pull 然后sh build腳本，我完全可以無縫的切到jekins，因為我是腳本呀，配置執行命令就好了呀。我把輸入判斷改為常量不就好了么。

nginx配置

我只做了最簡單nginx配置，沒有優化，我還沒空去細致研究，其實這一層還能做很多。但是我簡單的需求就是，通過域名的路徑去匹配頁面，然后proxy。當然我不是單一項目，而是多項目，這里會涉及正則。

附上例子代碼

server {listen 80;server_name _;charset utf-8;access_log /var/www/log/nginx_access.log main;error_log /var/www/log/nginx_error.log main;root /var/www/html/xxxx/;index index.html;location ^~ /api-xxx {proxy_pass http://www.xxxxx.com;}location ^~ /api-xxx {proxy_pass http://www.xxxxx.com;}location ^~ /aaa {alias /xxxx;try_files $uri /xxx/index.html;index index.html;}location ^~ /ccc {alias /xxxx;try_files $uri $uri/index.html $uri/ =404;index index.html;} } 復制代碼

首先，我這邊可能會有www.xxx.com/h5，www.xxx.com/admin的情況，而且我會根據/api-xxx的不同，去請求不同的服務。location ^~ /aaa 是針對spa的配置，location ^~ /ccc是針對靜態化頁面的配置。為啥我不用cdn去緩存html頁面呢？不好意思業務問題不贅述。上述只是例子代碼，你可以看思路，可別直接在線上用，業務不同需求不同。

總結：善用腳本解決問題，減少重復勞動。

mock平臺

首先你mock的平臺最好做到0業務入侵，只切換變量即可，要配合好注釋and文檔。我的端口可能面對pc、mobile、小程序等。首先瀏覽器端，我會針對webpack的開發配置做改動。小程序我會二次封裝wx.request。具體實現例子如下。

所有瀏覽器端

// 開發環境 webpack dev server配置 const PATH = require('../package.json').conf_liberty['path']; const URL = require('../package.json').conf_liberty['url'];"/api":{"target": URL[PATH],"pathRewrite": {"^/api-xxx": "/xxx",} } 復制代碼// package.json "conf_liberty": {"path": "mock","url": {"mock": "https://xxx.xxx.com/mock/xxx/" ,// mock 數據請求地址"test": "http://xxx.test.xxx.com", // 測試機的請求地址"pre": "http://xxx.xxx.com/", // 預發布的請求地址"online": "http://xxx.xxx.com/", // 正式環境的請求地址} } 復制代碼

小程序端

// config/url.js /*** 小程序配置文件、切換環境直接切換變量即可* @param mock 模擬數據環境* @param test 測試環境* @param pre 線上測試環境* @param online 正式環境*/ const envir = 'online';// 環境閥門 const configMap = {'mock': {// mock 數據請求地址url: 'https://xxx.xxx.com/mock/xxx/',},'test': {// 測試機的請求地址url: 'http://xxx.test.xxx.com',},'pre': {// 預發布的請求地址url: 'http://xxx.xxx.com/',},'online': {// 正式環境的請求地址url: 'http://xxx.xxx.com/',}, };const config = configMap[envir];module.exports = {baseUrl: config.url, }; 復制代碼// 二次封裝的wx.request // 為什么要封裝成class，因為我有業務擴展，看個思路即可。import {baseUrl} from '../config/url';class request {request(params) {return new Promise((resolve, reject) => {let params.url = baseUrl + params.url;wx.request({...params,success: (result) => {//},fail: (error) => {//},complete: (response) => {//},});});};} export default new request;復制代碼

每次開發，當開發人員和后端對好接口文檔，到mock服務器寫好mock，然后就可以在有數據的情況下愉快的開發了，而且的mock的數據更加全面帶有隨機性質符合前端開發人員需求，需要debug時甚至可以直接切換線上數據，但是操作線上數據需要時刻注意，這必須要引起開發人員重視。當然帶有上傳性質的接口，不太好測試。但是這點是可以解決的。需要和后端調試，我切換到test即可，多么的簡單。我認為前端的很多的bug問題，都是數據的多樣性導致開發人員沒有考慮到，所帶來的結果。

mock平臺的選擇

首先，我有兩個種做法上的選擇，線上服務器mock，本地服務器mock，我選擇了線上服務器mock做法，因為我mock的數據會越來越多，提交到git上真難看，而且本地寫json的形式，對于文檔的整理不太友好，并且業務線確實有點多，需要總線式的管理，所有果斷放棄。

接下來，我對比的easy-mock，yapi，云效平臺，三種mock服務器平臺之后，我選擇了yapi。先來說說我的標準，內網服務、搭建簡單、升級容易、依賴少、不花錢，另外2種不是不好，只是我的選擇而已。先說說easy-mock的我的看法，麻煩，依賴了Node、MongoDB、Redis，沒有一鍵安裝，一鍵化升級，甚至我還沒找到如何升級，也許我眼拙。云效平臺，我就看到了簡介，怎么用我都沒找到，阿里云的服務嘛，估計還要收費算了。來說說yapi，首先依賴輕，有Node、MongoDB就好了。安裝太簡單npm install -g yapi-cli，執行一下yapi server，配置一下數據庫，點一點就ok了。我就花了1個小時左右就搞定了。后續升級yapi update一下好了。多么的愉快。而且基本滿足我的需求，基本的mock、高級的mock、文檔導入導出非常完美，甚至能測試線上數據，簡單的postman功能也行，連nginx配置官方都幫我想好了。目前我已經在全部業務線使用，而且推薦給客戶端、后端同學使用，只能說好評連連。而且以我粗淺的能力，尚能看得懂yapi的機制，就算官方不維護了，我也能打打補丁。想知道如何安裝的，去yapi官網看就好了。

安裝方法

來說說我的安裝方法把，首先我會在本地安裝npm install -g yapi-cli，做好基本調試，配置好數據庫，我用的是遠程數據庫。寫好config.json基本配置，然后push到git上。到指定服務器pull即可，安好pm2，啟動。后續升級也是這樣，先本地升級測試一下，然后到服務器pull重啟，當然這是可以結合jekins。

總結：這種工具服務的選擇沒有啥對錯，只要符合當前業務開發，并且可以基本的持續迭代即可，自主研發也好，第三方服務也罷，怎么都行，一切以加速業務開發為導向。

私有的npm

首先業務線有點多，而且基本可以做到一些方法復用例如：客戶端版本判斷、UA檢測、統計服務、JSbridge等等，組件二次封裝等。例如：ant design的圖片上傳，你每次寫一堆配置，其實你需要配置的無非是action，disabled，onChange，name你是不是可以跟后端商量固定action，給一個當前業務的基礎接口做成業務組件。再極端一點，我完全可以做成npm包，讓后端同學提供一個完全獨立的服務。我發現很多前端，對于UI庫是真拿來主義，拿來就用，拜托，你有沒有發現，其實你每次用UI庫里面的東西，寫一坨不累么。人家組件是為了適應90%場景的，而你在實際業務中所用到可能不到10%。請你提高一下自己的效率可好？

例如：

// 經過二次封裝的上傳組建 let upladFileConf = {title: '上傳',// 按鈕內容disabled: false,// 是否禁用callBack: (e)=> this.handleUpload(e),// 成功回調callError: ()=> this.handleError(),// 失敗回調 }; <UpladFile {...upladFileConf}/> 復制代碼// 經過二次封裝的彈窗組件 const conf = {visible: visible,// 是否顯示title: '彈窗標題',// 標題onCancel: (res)=> this.props.onCancel(res),// 確定按鈕or取消按鈕，回調 };return (<Modal {...conf}></Modal> ) 復制代碼

私有npm服務選擇

先說我的需求，簡單好用，穩定，方便部署，及時通知，在我對比的cnpm、sinopia、verdaccio、Nexus之后。我的結論是verdaccio，cnpm感覺插件有點少貌似，沒有釘釘推送的插件，sinopia都涼了不考慮，Nexus吧沒必要，我就前端用用而已。verdaccio目前看到還行，繼承了sinopia，插件滿足我的需求，安裝簡單，上線小半年沒啥問題，目前有十幾個私有包，連數據庫都不用折騰。路徑切換選擇用nrm即可。

安裝方法

首先我依舊會在本地安裝好，npm install -g verdaccio，配置好config.yaml，裝好釘釘通知，做好目錄屏蔽，然后遷移到我的git中，然后書寫shell腳本。

# build.sh # /bin/bash # 啟動私有npm腳本work_path=$(pwd) verdaccio --listen 4873 --config ${work_path}"/verdaccio/config.yaml" 復制代碼

然后每次我需要調試配置時，我先在本地測試，push一下，到服務器pull一下，執行pm2 start build.sh或者pm2 restart build。當然這也是可以加到jekins。

注意

yaml這種配置文件請認真去研究一下怎么寫，縮進空格有點不同。storage/.sinopia-db.json一定要是json格式不能為空，而且內容可以是{"list":[],"secret":""}

總結：其實搭建私有npm不難，難在如何設置私有npm包的發布規則，互相依賴升級等，可以用lerna來做。私有npm規則，以及lerna的使用，等我稍后總結。

項目模版

每次new cli我不反對，但是真的不累么，那么多包要加，有些特有的地方架子還要改。目前我總結出3套，ant-admin-template、nuxt-mobile-template、spa-mobile-template。

實現方法（只以admin例子）

新開目錄，然后執行new cli，生成基礎項目模版。對基礎模版做一些調整，并且安裝一些基礎包

調整的基礎模版

|----- dist/ 正式環境產出 |----- conf/ 配置文件|----- alias.js 公共路徑配置文件|----- development.js 開發環境配置文件|----- production.js 正式環境配置文件|----- oss.js build之后將文件上傳到oss |----- src/ 開發目錄|----- components/ 公共業務組件|----- pages/ 頁面|----- hoc/ HOC|----- serverice/ 中間層|----- utils/ 通用方法|----- index.css 主css|----- index.js 主入口文件|----- router.js 路由裝載配置 |----- .editorconfig 統一開發格式配置文件 |----- .eslintrc 開發格式配置文件 |----- .webpackrc.js webpack配置文件 |----- .gitignore git提交屏蔽文件 |----- package.json npm配置文件 |----- index.ejs index.html模版文件-------------分割線----------------scr/pages pages |----- index.js 出口文件 |----- [name]Page 集成業務代碼|----- index.js 集成頁面view，model，router|----- components 當前業務專屬組件|----- index.js view層|----- [name] 業務文件夾|----- model.js model層|----- [name]Component.js 當前page專屬組件 復制代碼

可能用到的插件包，可自行刪減

{"axios": "^0.18.0","prop-types": "^15.6.1","qs": "^6.7.0","ali-oss": "^6.0.1","underscore": "^1.9.1","husky": "1.1.2","@xxx/xxx": "^x.x.x", // 私有包 } 復制代碼

制作完成，push到git中，如果需要新開管理臺，只要pull，npm i，改改nginx即可。nginx我已經腳本化了，很簡單就能部署。

注意

登陸、退出、鑒權，預留空間出來，因為每個項目都會有細微差別，讓開發人員自行修改即可。

總結：這種項目模版形式，快速開發新業務線，例如運營管理臺、財務管理臺、等等內部管理臺使用，或者作為spa骨架，小程序骨架，pc骨架，為啥要開這么多管理臺？少年，你，財務系統、erp系統、cms系統、售后系統，真的不要切分開來么？有精力做權限切分，搞的一個項目臃腫不堪，不如獨立。每個平臺有自己的賬戶登陸權限。簡單省事，反正都是一套架子，也不存在什么跨項目。升級的話，基礎目錄即結構不變，升級npm包、升級私有npm包即可。請記住，看上去合并很容易，但復雜度高。分開會加速開發，同時降低復雜度。

服務器初始化

快速在服務器上安裝git、nrm、nvm，當然這個是一次性的，后續我做鏡像即可。當然有些特殊情況，我也會用到，例如我要制作新的鏡像。直接貼代碼把不解釋了。

安裝git

#!/bin/bash # 安裝最新git # 需要exit之后再次進入機器，git命令才會生效 yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel asciidoc wget yum install gcc perl-ExtUtils-MakeMaker yum remove git cd /usr/local/src/ wget https://www.kernel.org/pub/software/scm/git/git-2.15.1.tar.xz tar -vxf git-2.15.1.tar.xz cd git-2.15.1 make prefix=/usr/local/git all make prefix=/usr/local/git install echo "export PATH=$PATH:/usr/local/git/bin" >> /etc/profile source /etc/profile git --version 復制代碼

安裝nvm

#!/bin/bash # 安裝nvm作為node版本控制 # 需要exit之后再次進入機器，nvm命令才會生效 wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash 復制代碼

安裝nrm

#!/bin/bash # 安裝nrm作為npm線路控制 npm install -g nrm nrm ls 復制代碼

注意：先安裝git、nvm，再安裝nrm

總結：拒絕重復勞動，我只需要touch git.sh && vim git.sh，拷貝代碼，執行即可。當然你可以說制作docker鏡像，目前我還沒研究透徹。公司專業的運維同學也怪忙的，我只能稍微請教一番，還是我自己先動手把。

非代碼層面的測試交付

代碼層面，通過mock、eslint、code review、單元測試等手段測試可以良好把控。前端程序員很多問題都是跨端，不同app版本測試所帶來的。這里我會要求開發人員空出一天或者半天時間，整理業務點，梳理測試的表格。當然也會有，沒有測試到的點，這可以通過補充慢慢完善。這東西一般會在大促使用、或者是重要功能，重要項目使用。梳理完成之后，我都會要求開發人員以郵件形式抄送給我，我會二次檢查，在項目上線半天前，我會再次要求開發人員以郵件形式抄送給我查看情況，預留給績效考核，以及我再次檢查確認是否有遺漏。

例如：

移動端

• UI兼容測試
  • iphoneX
    • xxx頁面
    • xxx頁面
    • xxx頁面
  • iPhone XS
    • xxx頁面
    • xxx頁面
    • xxx頁面
  • iphone8
    • xxx頁面
    • xxx頁面
    • xxx頁面
  • 小米8
    • xxx頁面
    • xxx頁面
    • xxx頁面
  • 小米7
    • xxx頁面
    • xxx頁面
    • xxx頁面
  • 紅米
    • xxx頁面
    • xxx頁面
    • xxx頁面

andorid版本測試

• x.x.x

  • 頁面功能點
  • 頁面功能點
  • 頁面功能點
  • 頁面功能點

• x.x.x

  • 頁面功能點
  • 頁面功能點
  • 頁面功能點
  • 頁面功能點

ios版本測試

• x.x.x

  • 頁面功能點
  • 頁面功能點
  • 頁面功能點
  • 頁面功能點

• x.x.x

  • 頁面功能點
  • 頁面功能點
  • 頁面功能點
  • 頁面功能點

微信端測試

• x.x.x
  • 頁面功能點
  • 頁面功能點
  • 頁面功能點
  • 頁面功能點

pc端

UI兼容測試

• xx瀏覽器 x.x.x版本
  • xxx頁面
  • xxx頁面
  • xxx頁面
• xx瀏覽器 x.x.x版本
  • xxx頁面
  • xxx頁面
  • xxx頁面

xx瀏覽器 x.x.x版本功能測試

• 頁面功能點
• 頁面功能點
• 頁面功能點
• 頁面功能點

xx瀏覽器 x.x.x版本功能測試

• 頁面功能點
• 頁面功能點
• 頁面功能點
• 頁面功能點

總結：不是有專業的測試人員么？不好意思，作為程序員自測都不能通過，還寫啥代碼，還寫啥好代碼。bug是跟績效掛鉤的，就問你要錢嗎？績效漂亮了，每個季度發錢，大大的給，不爽么？你出去找工作底氣足嗎？大聲喊出，我有完備的測試流程，我寫的代碼基本0bug，不驕傲么？

錯誤監控

抓取頁面js異常，上報UA/錯誤提示信息、分析日志/5xx/4xx、CDN異常監控、設置n min之內5xx，4xx閾值，這些都是基礎運維服務的東西不深入。關注小程序的開發 > 錯誤查詢/性能監控/告警設置。這一塊我尚未特別深入，其實都是阿里云的服務設置一下，或者每天檢查微信公眾平臺，或者使用第三方監控平臺。有機會詳談。

總結：錯誤監控，大部分都是基于日志系統的，前端唯一特殊的點就是會有js報錯的情況，稱之為崩潰率。反正基于日志就對了。pv、uv的？？？？喵喵喵

獲取最新信息

請用rss訂閱的方式，訂閱你所使用的開源項目，第一時間獲取，version信息、commit信息、fixbug信息，作為leader你要時刻掌握最新咨詢，而不是被人告知。

結語

不好意思，洋洋灑灑寫了這么多，能看到這里的，也不容易，牛逼了老弟/老哥/老妹/老姐。說老實話，還有很多地方沒說，例如：腳本化小程序發布、腳本化發布多個端的小程序、eslint的使用細節、webhook的使用如何禁止merge、githook細節、commit log 規范、打tag包、釘釘的推送、cdn部署、code review的標準、npm包的標準、單元測試的普及、性能監控、api切分、用中間頁鑒權、設備指紋、支付安全、將bs構架快讀切換cs構架、如何保證多個項目同時在測試環境同時交付測試、灰度發布等等還有很多東西把，這些就等我慢慢體驗了，慢慢整理了。

這些東西為就不能稱之為架構，只是我個人的一些逗比操作而已，這套東西3～10人小團隊，20條業務線，給我的感覺是可以撐住的。前提是在業務量在高速增長的情況下使用。我曾經問過我師傅，為啥，他在的時候不做，明明他都懂。他回答的是：“公司在什么階段做什么事情，當公司在尋找主營業務，不停試錯時，你固化的構架，就不適合這家公司，當公司尋找到這個點之后，你用構架就能快速輔助開發，業務其實沒啥寫的，就看怎么寫的快，跟上市場，讓公司能快速響應市場，或者引領市場”。好吧，我服氣

總結

以上是生活随笔為你收集整理的006.不浅谈，数十条业务线以上的，前端小团队瞎逼基础服务思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。