工做流程以及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海之中没法自拔，不过也给了你一些找新东家面试的时候和面试官侃侃而谈情到深处抱头痛哭的东西。

`TypeScript` 真香啊真香

ts之于项目的意义，用any则死，用never则生，宽进严出是无数老前辈总结出来的经验教训，多写几个never老是没错的，大不了之后删。那么问题来了，从哪开始用，固然是在你拉接口的那一刻起