摘要：今天順便總結(jié)了下之前的一些經(jīng)驗(yàn)，希望對(duì)大家的工作或者學(xué)習(xí)有一些幫助。老生常談的啥的就不多說了，簡(jiǎn)單分享些插件和配置功能優(yōu)化，方便大家更省力地寫代碼。另外，的正規(guī)操作常用于服務(wù)端項(xiàng)目的發(fā)布，增加了不少靈活性，一下子解放了運(yùn)維大哥。

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

今天順便總結(jié)了下之前的一些經(jīng)驗(yàn)，希望對(duì)大家的工作或者學(xué)習(xí)有一些幫助。
老生常談的splitChunks、Dll啥的就不多說了，簡(jiǎn)單分享些插件和配置功能優(yōu)化，方便大家更省力地寫代碼。

很多時(shí)候我們?yōu)榱丝缬驎?huì)給devServer配個(gè)proxy啥的，沒數(shù)據(jù)的時(shí)候要連接到mock接口上，有數(shù)據(jù)的時(shí)候又要切換到dev上，有時(shí)候又要調(diào)試復(fù)現(xiàn)qa環(huán)境的問題，一般像這個(gè)時(shí)候我們可以簡(jiǎn)單配個(gè)npm script

    # 默認(rèn) dev 環(huán)境
    npm run dev

    # mock 環(huán)境
    npm run dev --mock 

那對(duì)webpack怎么配置呢

新建一個(gè)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;

然后導(dǎo)入到你的webpack.config.dev.js中，設(shè)置為devServer的proxy

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

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

然后就完事了，當(dāng)然了，這是最簡(jiǎn)單的方式，一般情況下我們是還需要根據(jù)當(dāng)前運(yùn)行的環(huán)境變量再做判定的。業(yè)務(wù)上的問題這里就不展開了。

很多時(shí)候我們會(huì)在項(xiàng)目運(yùn)行或者打包的時(shí)候出現(xiàn)一大堆沒啥用的信息，
改下webpack里的stats即可
開發(fā)環(huán)境也可以用friendly-errors-webpack-plugin也是挺方便的

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

這個(gè)是之前在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()
    ]

然后你就可以在打完包后來一個(gè)依賴分析,用著也挺方便的

    npm run build --report

有些利用travis 或者jenkins做遠(yuǎn)端打包的項(xiàng)目，在項(xiàng)目發(fā)布前可以簡(jiǎn)單配置一個(gè)郵件功能，包含打包內(nèi)容、git commit信息什么的， 就不需要專門找人一一告知，方便所有開發(fā)人員根據(jù)業(yè)務(wù)，提高開發(fā)效率。
推薦nodemailer

很多時(shí)候npm script 可能不夠用或者說看上去并不怎么直觀，因?yàn)闆]法寫備注可能也說不清具體什么用
這時(shí)候可以使用Makefile
在根目錄建個(gè)Makefile文件
然后就可以在里面配置一些基本命令，可以理解為對(duì)npm script做一個(gè)簡(jiǎn)單的封裝，關(guān)鍵是可以寫備注

# 開發(fā)
start:
    npm run dev

# 打包
build:
    npm run build

# mock環(huán)境
mock:
    npm run dev --mock

然后你在當(dāng)前目錄下輸入

    make start

就可以開始干活了

線上環(huán)境為了保證用戶隱私是不允許開發(fā)人員直接接觸用戶信息的，但是有些問題光靠公司現(xiàn)有的測(cè)試機(jī)也無法完全覆蓋，異常跟蹤的框架網(wǎng)上挺多，這里簡(jiǎn)單提一下不做深入討論。

開源常用的是sentry，具體怎么用自己看，弄個(gè)docker鏡像跑一下啥的還是挺方便的。
收費(fèi)的市面上不少，就不打廣告了。

如果業(yè)務(wù)中涉及到一些server端的開發(fā)的話肯定要解決各類服務(wù)端軟件的安裝比如Redis，MySql MongoDB等，而不同項(xiàng)目可能還需要不同版本的數(shù)據(jù)庫(kù)，甚至還可能要考慮node的版本，而各種版本的切換是一個(gè)讓人頭疼的事情，甚至因?yàn)槟承┰蜻€要兩個(gè)版本同時(shí)運(yùn)行在一臺(tái)機(jī)器上，那怎么辦呢？
于是我們開始考慮引入使用docker

Docker的基本使用就是簡(jiǎn)單的找個(gè)鏡像 install 然后 run 就行了，
-v掛上持久化， -p 掛上端口

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

類似這樣就能直接在機(jī)器上掛上最新的redis鏡像并映射到本地6379端口，簡(jiǎn)單粗暴，再掛下持久化啥的丟到 Makefile 里直接運(yùn)行就行了，用的人也不需要費(fèi)時(shí)費(fèi)力地去裝redis
同理如果對(duì)node也有要求的話

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

直接運(yùn)行上面這行命令就可以直接在 docker 中直接運(yùn)行打開bash輸入框運(yùn)行 node 環(huán)境進(jìn)行開發(fā)了，這樣即使用戶機(jī)器上沒有 node 也照樣可以開發(fā) node 程序，不過以上只是直接創(chuàng)建了同名鏡像，容易被其他項(xiàng)目覆蓋，真實(shí)環(huán)境別直接這樣做，出問題了我可不負(fù)責(zé)的啊。而且性能啥的也不是特別好。
有必要的話還是建議學(xué)習(xí)下 docker 能幫你解決不少事。
另外， Docker 的正規(guī)操作常用于服務(wù)端項(xiàng)目的發(fā)布，增加了不少靈活性，一下子解放了運(yùn)維大哥。
當(dāng)然以上的介紹連冰山一角都不到，我也是正在學(xué)習(xí)Docker。

之前寫了兩年 vue 后來又寫了一年react
順便在這里總結(jié)下這幾年項(xiàng)目開發(fā)的經(jīng)驗(yàn)

在接手一個(gè)用了 redux 或者 vuex 的項(xiàng)目的時(shí)候是否經(jīng)常感覺很頭大不知道從哪個(gè)地方開始看代碼，一會(huì)要看看view層 一會(huì)又要回到model層招model。
而使用那種mvc一樣的目錄結(jié)構(gòu)導(dǎo)致兩個(gè)東西間隔了大老遠(yuǎn)一會(huì)要進(jìn)page目錄找組件 一會(huì)又要進(jìn)store目錄找狀態(tài)
這種事情對(duì)于一個(gè)單人寫的短平快的項(xiàng)目還好，對(duì)于一個(gè)需要長(zhǎng)期維護(hù)的業(yè)務(wù)來說是否有時(shí)候會(huì)讓人感到無所適從
產(chǎn)品需求一個(gè)接一個(gè)的加，接口數(shù)量和字段也在一個(gè)個(gè)地加，而為解決一些老版本的兼容問題，一些老接口的冗余字段已經(jīng)堆積成山，有的已經(jīng)廢棄，而有的還茍延殘喘在你的代碼中讓你苦不堪言。

所以，我做了哪些思考呢

    package.json
    ...
    
    `src`
        - app.ts                          // 總?cè)肟?        - router.ts                       // 路由
        - `store`                         // 公共倉(cāng)庫(kù)
            - index.ts                    // 公共倉(cāng)庫(kù)總?cè)肟?        - `page`                          // 放頁面的地方
            - index.ts                    // page總?cè)肟?，所有頁面從這導(dǎo)出
            - `[例：PAGEA]`               
               - README.md                // 說明文檔
               - index.ts                 // 入口
               - `view`                   // 業(yè)務(wù)相關(guān)頁面組件
                   - index.tsx
                   - componentA.tsx
                   - style.less
               - `service`                // 放接口的地方
                   - index.ts
               - `model`
                   - index.ts
        - `component`                     // 放些雜七雜八的公共組件的，比如編輯器啥的
            - index.ts                    // 總?cè)肟冢薪M件從這導(dǎo)出
            - `[例：COMPONENTA]`
                - index.tsx       
                - style.less
                - README.md              // 說明文檔
        - `util`                         // 工具函數(shù)
            - index.ts                   // 工具函數(shù)總?cè)肟?            - `[例：UTILA]`
                - index.ts
                - README.md              // 說明文檔  
    

每個(gè)頁面在迭代的時(shí)候?qū)懮细抡f明，標(biāo)上原型地址，接口上附上api文檔地址，至少讓人家知道這個(gè)頁面是從哪個(gè)年代開始寫起來的干了啥不得了的事又砍了啥功能

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

像啥三幾次方元表達(dá)式，
obj && obj.list && obj.list[0] && obj.list[0].value之類寧死不賦默認(rèn)值不做預(yù)數(shù)據(jù)處理的拿過來接口就是干的東西，
value1 , value2 之類的命名習(xí)慣統(tǒng)統(tǒng)打回

歷史的慘痛經(jīng)驗(yàn)教訓(xùn)告訴我們，如果有些東西你只是標(biāo)個(gè)warning那么在不久的將來，你在啟動(dòng)項(xiàng)目之后就會(huì)看到一條長(zhǎng)長(zhǎng)的黃色的海洋。
那我要這warning有何用！還不如直接去掉。

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

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

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

ts之于項(xiàng)目的意義，用any則死，用never則生，寬進(jìn)嚴(yán)出是無數(shù)老前輩總結(jié)出來的經(jīng)驗(yàn)教訓(xùn)，多寫幾個(gè)never總是沒錯(cuò)的，大不了以后刪。
那么問題來了，從哪開始用，當(dāng)然是在你拉接口的那一刻起