摘要：今天順便總結了下之前的一些經驗，希望對大家的工作或者學習有一些幫助。老生常談的啥的就不多說了，簡單分享些插件和配置功能優化，方便大家更省力地寫代碼。另外，的正規操作常用于服務端項目的發布，增加了不少靈活性，一下子解放了運維大哥。

前端工程化這些事情現在已經算是深入人心了，即便不清楚具體含義vue-cli creat-react-app之類的腳手架也幫助大家快速開發了不少項目。

今天順便總結了下之前的一些經驗，希望對大家的工作或者學習有一些幫助。
老生常談的splitChunks、Dll啥的就不多說了，簡單分享些插件和配置功能優化，方便大家更省力地寫代碼。

很多時候我們為了跨域會給devServer配個proxy啥的，沒數據的時候要連接到mock接口上，有數據的時候又要切換到dev上，有時候又要調試復現qa環境的問題，一般像這個時候我們可以簡單配個npm script

    # 默認 dev 環境
    npm run dev

    # mock 環境
    npm run dev --mock 

那對webpack怎么配置呢

新建一個proxy.js文件

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的proxy

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

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

然后就完事了，當然了，這是最簡單的方式，一般情況下我們是還需要根據當前運行的環境變量再做判定的。業務上的問題這里就不展開了。

很多時候我們會在項目運行或者打包的時候出現一大堆沒啥用的信息，
改下webpack里的stats即可
開發環境也可以用friendly-errors-webpack-plugin也是挺方便的

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

這個是之前在vue-cli上找的，用著感覺也挺順手的，

# 下載插件
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

有些利用travis 或者jenkins做遠端打包的項目，在項目發布前可以簡單配置一個郵件功能，包含打包內容、git commit信息什么的， 就不需要專門找人一一告知，方便所有開發人員根據業務，提高開發效率。
推薦nodemailer

很多時候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的基本使用就是簡單的找個鏡像 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              // 說明文檔  
    

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

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

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

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

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

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

所以個人感覺GraphQL在現階段并不是必須要學，學會了也可能用不到，用到了可能在產品瘋狂改需求的結果下讓你在后端各類神奇的騷操作之下迷失在茫茫query海之中無法自拔，不過也給了你一些找新東家面試的時候和面試官侃侃而談情到深處抱頭痛哭的東西。

ts之于項目的意義，用any則死，用never則生，寬進嚴出是無數老前輩總結出來的經驗教訓，多寫幾個never總是沒錯的，大不了以后刪。
那么問題來了，從哪開始用，當然是在你拉接口的那一刻起