工做流程以及webpack配置一些優化以及經驗教訓

時間 2019-12-09

標籤流程以及 webpack 配置一些優化經驗教訓简体版

原文原文鏈接

前端工程化這些事情如今已經算是深刻人心了，即使不清楚具體含義vue-cli creat-react-app之類的腳手架也幫助你們快速開發了很多項目。前端

今天順便總結了下以前的一些經驗，但願對你們的工做或者學習有一些幫助。
老生常談的splitChunks、Dll啥的就很少說了，簡單分享些插件和配置功能優化，方便你們更省力地寫代碼。vue

配置

1. 代理配置：

不少時候咱們爲了跨域會給devServer配個proxy啥的，沒數據的時候要鏈接到mock接口上，有數據的時候又要切換到dev上，有時候又要調試復現qa環境的問題，通常像這個時候咱們能夠簡單配個npm scriptnode

# 默認 dev 環境
    npm run dev

    # mock 環境
    npm run dev --mock

那對webpack怎麼配置呢mysql

新建一個proxy.js文件react

const config = {
    dev: {
         ... // 你的proxy配置 文檔自行參考 https://webpack.js.org/configuration/dev-server/#devserver-proxy  
    },
    mock: {
        ...
    }
};

let proxy = config.dev;

for (const key in proxy) {
    if (process.env[`npm_config_${key}`]) {
        current = { ...proxy, ...config[key] };
    };
};
module.exports = current;

而後導入到你的webpack.config.dev.js中，設置爲devServer的proxywebpack

const proxy = require('./proxy.js');

...
devServer: {
    ...
    proxy: proxy
}

而後就完事了，固然了，這是最簡單的方式，通常狀況下咱們是還須要根據當前運行的環境變量再作斷定的。業務上的問題這裏就不展開了。git

2. log信息

不少時候咱們會在項目運行或者打包的時候出現一大堆沒啥用的信息，
改下webpack裏的stats便可
開發環境也能夠用friendly-errors-webpack-plugin也是挺方便的程序員

3.sourceMap

開發環境隨便配個喜歡的sourceMap就好，可是生產環境就要去掉了，固然爲了方便qa調試，最好也爲打包作好各類環境設置，
可是別把sourcemap打到業務代碼裏是每一個程序員的基本素養。對，我說的就是inline-source-map這種配置，有的話趕忙改掉，相信我這是爲了你的職業生涯考慮。生產環境要用也只能用source-map,而後讓運維大哥隨手屏蔽下全部.map文件便可。github

功能插件

1. 依賴分析

這個是以前在vue-cli上找的，用着感受也挺順手的，web

# 下載插件
npm i -D webpack-bundle-analyzer

// 注入webpack.config.prod.js
    const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');
    
    // 寫入plugin     
    ...
    plugins: [
        process.env.npm_config_report && new BundleAnalyzerPlugin()
    ]

而後你就能夠在打完包後來一個依賴分析,用着也挺方便的

npm run build --report

2. 郵件

有些利用travis 或者jenkins作遠端打包的項目，在項目發佈前能夠簡單配置一個郵件功能，包含打包內容、git commit信息什麼的，就不須要專門找人一一告知，方便全部開發人員根據業務，提升開發效率。
推薦nodemailer

工做流程優化

Makefile

不少時候npm script 可能不夠用或者說看上去並不怎麼直觀，由於無法寫備註可能也說不清具體什麼用
這時候可使用Makefile
在根目錄建個Makefile文件
而後就能夠在裏面配置一些基本命令，能夠理解爲對npm script作一個簡單的封裝，關鍵是能夠寫備註

# 開發
start:
    npm run dev

# 打包
build:
    npm run build

# mock環境
mock:
    npm run dev --mock

而後你在當前目錄下輸入

make start

就能夠開始幹活了

異常追蹤

線上環境爲了保證用戶隱私是不容許開發人員直接接觸用戶信息的，可是有些問題光靠公司現有的測試機也沒法徹底覆蓋，異常跟蹤的框架網上挺多，這裏簡單提一下不作深刻討論。

開源經常使用的是sentry，具體怎麼用本身看，弄個docker鏡像跑一下啥的仍是挺方便的。
收費的市面上很多，就不打廣告了。

其餘環境

若是業務中涉及到一些server端的開發的話確定要解決各種服務端軟件的安裝好比Redis，MySql MongoDB等，而不一樣項目可能還須要不一樣版本的數據庫，甚至還可能要考慮node的版本，而各類版本的切換是一個讓人頭疼的事情，甚至由於某些緣由還要兩個版本同時運行在一臺機器上，那怎麼辦呢？
因而咱們開始考慮引入使用docker

Docker

Docker的基本使用就是簡單的找個鏡像 install 而後 run 就好了，
-v掛上持久化， -p 掛上端口

# 例 ：redis
    $ docker run -d -p 6379:6379 redis

相似這樣就能直接在機器上掛上最新的redis鏡像並映射到本地6379端口，簡單粗暴，再掛下持久化啥的丟到 Makefile 裏直接運行就好了，用的人也不須要費時費力地去裝redis
同理若是對node也有要求的話

docker run -t -i -p 8000:8000 -w /project -v $PWD:/project node:11.3.0 /bin/bash

直接運行上面這行命令就能夠直接在 docker 中直接運行打開bash輸入框運行 node 環境進行開發了，這樣即便用戶機器上沒有 node 也照樣能夠開發 node 程序，不過以上只是直接建立了同名鏡像，容易被其餘項目覆蓋，真實環境別直接這樣作，出問題了我可不負責的啊。並且性能啥的也不是特別好。
有必要的話仍是建議學習下 docker 能幫你解決很多事。
另外， Docker 的正規操做經常使用於服務端項目的發佈，增長了很多靈活性，一會兒解放了運維大哥。
固然以上的介紹連冰山一角都不到，我也是正在學習Docker。

業務開發的經驗教訓

以前寫了兩年 vue 後來又寫了一年react
順便在這裏總結下這幾年項目開發的經驗

在接手一個用了 redux 或者 vuex 的項目的時候是否常常感受很頭大不知道從哪一個地方開始看代碼，一會要看看view層一會又要回到model層招model。
而使用那種mvc同樣的目錄結構致使兩個東西間隔了大老遠一會要進page目錄找組件一會又要進store目錄找狀態
這種事情對於一個單人寫的短平快的項目還好，對於一個須要長期維護的業務來講是否有時候會讓人感到無所適從
產品需求一個接一個的加，接口數量和字段也在一個個地加，而爲解決一些老版本的兼容問題，一些老接口的冗餘字段已經堆積成山，有的已經廢棄，而有的還苟延殘喘在你的代碼中讓你苦不堪言。

因此，我作了哪些思考呢

丟上目錄

package.json
    ...
    
    `src`
        - app.ts                          // 總入口
        - router.ts                       // 路由
        - `store`                         // 公共倉庫
            - index.ts                    // 公共倉庫總入口
        - `page`                          // 放頁面的地方
            - index.ts                    // page總入口，全部頁面從這導出
            - `[例：PAGEA]`               
               - README.md                // 說明文檔
               - index.ts                 // 入口
               - `view`                   // 業務相關頁面組件
                   - index.tsx
                   - componentA.tsx
                   - style.less
               - `service`                // 放接口的地方
                   - index.ts
               - `model`
                   - index.ts
        - `component`                     // 放些雜七雜八的公共組件的，好比編輯器啥的
            - index.ts                    // 總入口，全部組件從這導出
            - `[例：COMPONENTA]`
                - index.tsx       
                - style.less
                - README.md              // 說明文檔
        - `util`                         // 工具函數
            - index.ts                   // 工具函數總入口
            - `[例：UTILA]`
                - index.ts
                - README.md              // 說明文檔

1. 硬性規定

前端也必須寫文檔

每一個頁面在迭代的時候寫上更新說明，標上原型地址，接口上附上api文檔地址，至少讓人家知道這個頁面是從哪一個年代開始寫起來的幹了啥不得了的事又砍了啥功能

公共組件也必須寫文檔，而且不能涉及任何業務相關功能

不少人爲了方便把組件抽出來作成一個公共組件啥都不寫丟在外面還說別人不懂組件的複用啥的逼叨逼一大堆結果連個基本說明文檔都不寫，別人好不容易用上了哪天需求一更新又加上點啥功能又擔憂別人的代碼裏出啥幺蛾子就寫一大堆if else 最後變成一坨越堆越高的翔
我的一直認爲，勉強複用的東西不如不用。

不容許寫的代碼直接打回重作

像啥三幾回方元表達式，
obj && obj.list && obj.list[0] && obj.list[0].value之類寧死不賦默認值不作預數據處理的拿過來接口就是乾的東西，
value1 , value2 之類的命名習慣通通打回

2. 軟件

`eslint`、 `tslint` 能加的都給加上能標 error 的絕對不標 warning

歷史的慘痛經驗教訓告訴咱們，若是有些東西你只是標個warning那麼在不久的未來，你在啓動項目以後就會看到一條長長的黃色的海洋。
那我要這warning有何用！還不如直接去掉。

`GraphQL` 挺好但現狀依舊不是特別樂觀

在用GraphQL以前不大看好這東西，感受就是一個掛羊頭賣狗肉的Restful，放出來好多年社區支持得也不怎麼樣。
後來在內部本身的小項目中用了之後呢，感受確實挺香，前端自定義接口內容的意義遠比後端給啥用啥來得舒坦...只要後端不隨便改聲明。。。
但需求這種事情呢，變起來翻天覆地，GraphQL雖然能在小迭代中發揮很多靈活性。

但後端不樂意用啊，甚至若是沒有方便的文檔工具，後端甚至可能會用word給你寫接口文檔，一個迭代發你一個doc文件，之前的接口文檔能找獲得給你發來，等這個後端一離職一交接，這個接口立馬原地爆炸。

因此我的感受GraphQL在現階段並非必需要學，學會了也可能用不到，用到了可能在產品瘋狂改需求的結果下讓你在後端各種神奇的騷操做之下迷失在茫茫query海之中沒法自拔，不過也給了你一些找新東家面試的時候和麪試官侃侃而談情到深處抱頭痛哭的東西。