前端工程化（二）：规范

前言

本文属于《前端工程化系列》的标准&规范介绍，该系列主要介绍我们一整套前端工程化解决方案。文章会由浅入深的来介绍如何实现前端工程化，以及一整套开箱即用的开源前端工程化解决方案。

文章主要面向中小型团队与新手，希望我们的这一整套工程化之路和解决思路可以帮助团队与开发者提效。

Review 标准

• 提交 review 前请务必仔细阅读自己修改的模块和设计到相关业务的影响，不要将未经开发者自查的代码提交 review
• 如有必要请写清楚注释，需要做到 review 审核者能清晰理解当前修改的程度
• 如有必要请在 commit 中标注具体哪个需求的开发任务，参考 comment #issue_ident
• 请保障在提交 review 之前运行测试，或完成自测，已减少重复提交 review 的情况
• 请不要选择超过 4个 的评审员，过多的人员的评审绝对弊大于利
• 评审员的选择如果可以尽量保持 2资深 + 1初级，资深程序员能对你的代码提供建议，初级程序员能从 review 中快速得到成长和熟悉项目
• Code review 绝对优先，我们提倡的准则是当团队中出现 code review 的时候往往是团队成员完成某项功能需要发布或其他的紧急情况，请保持在收到 review 的当天半天时间内优先处理 review
• Show Code 我们推荐每周在周会上抽出当周最佳 code review 和 bad case，直面问题会让团队中每一个成员快速成长

分支管理

版本管理

• 前后端分离发布
• master 分支受到保护且仅来源于 release 分支
• release 作为发布分支，且仅接受 daily 分支代码 merge 发布
• hotfix 可作为紧急发布分支，需要在发布之后 review merge 进 release 分支
• daily 作为 日常/版本 功能开发使用，每次迭代需要从 master checkout 出来新版本，daily 分支代码来源于 dev 分支的 merge
• dev 分支从 daily 分支切出可作为迭代内功能多个开发者相互 review

Commit 规范

1. 可以使用 one-cli 的 cz 命令针对项目进行 git-commitizen 的一键配置。
2. 手动提交建议按照如下规则提供每次 commit 信息

代码规范

如果你想直接有一套严格但是不严苛的编码规范，那向你推荐使用 umi-fabric，一个包含 prettier，eslint，stylelint 的配置文件合集。开箱即用的同时，你也可以通过自定义规则符合自己的习惯。

npm i @umijs/fabric --save-dev
yarn add @umijs/fabric -D

eslint 配置

# .eslintrc.js 文件配置

module.exports = {
  extends: [require.resolve('@umijs/fabric/dist/eslint')],

  rules: {
    // your rules
  },
};

stylelint 配置

# .stylelintrc.js 文件配置
module.exports = {
  extends: [require.resolve('@umijs/fabric/dist/stylelint')],
  rules: {
    // your rules
  },
};

prettier 配置

# .prettierrc.js 文件配置
const fabric = require('@umijs/fabric');

module.exports = {
  ...fabric.prettier,
};

拓展阅读

前端工程化（一）：工程化开篇