乐趣区

关于javascript:前端工程化二规范

jiezi

前言

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

文章次要面向 中小型团队与老手，心愿咱们的这一整套工程化之路和解决思路能够帮忙团队与开发者提效。

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,};

拓展浏览

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

退出移动版