日常规范

  • 不写过于奇技淫巧的方法, 后期的成本会减少很多
  • 使用高质量的静态分析工具, 如 TypeScript, 减少错误、同一代码风格; 或者使用 monorepo
  • Code Review

设计规范

  • 视觉和交互应符合规范, 找设计师确认交互设计和视觉还原度是否合格

开发规范

  • 不要在 master 上开发, 来一个新的分支出来, 便于后续提 mergeRequest
  • 保证所有的 src\ 目录下的 .js 文件都通过 eslint 的规则检测
  • 如果有配套的单元测试, 需要让所有的单元测试通过
  • 删除 build / dist 目录, 不允许将其提交到 git 中
  • 组件开发完毕后, 建议本地新建分支, 然后 push 到远端, 在远端发起 MergeRequest 到主干, 之后找相关人员进行 CodeReview
  • README.md 应按照模版的结构补充, 便于后期维护; 如果有逻辑复杂的组件, 在 README.md 中补充设计文档
  • History.md 在版本变更时应添加对应的变更纪要

提交规范

  • 提交的时候如果东西比较多, 就分次上传, 做好提交记录 (第一行是标题, 第二行是空行, 第三行是描述);
    • 一个 pr (pullRequest) 上可以有多次提交
    • 在 sourcetree 上, 如果一个问题操作过多个文件, 有一个 stage hunk, 选中这个问题所修改的代码即可提交该问题所修改的行, 而不是把这一个文件通过一个 commit 直接提交
  • 如果发现提交完了之后还有一些没有随着本次 commit, 直接选中需要补提交的文件, 在 commit options 里选择 amend last commit, 即可补提交上次的 commit
  • 版本号策略, 参考 semver
  • 进行组件发布自测, 如从 1.x.x 升级到 2.0.0, 在自测时
    • 提交 mergeRequest 后, CodeReview 之前, 只能发布 beta 版; 如 package.json 的 version 修改为 1.x.x-beta.1
    • 发布测试包 (npm run build & npm publish)
    • 在日常环境中新建一个项目
    • 将组件及版本号配置到应用设置 -> 组件依赖配置中
    • 进行测试、检测
    • 确认没问题后, 发布组件

flow-typed 规范

  • 更新 依赖 & flow-typed & package.json 不要和编辑逻辑混在一起, 单独上传一次
  • 当安装一个新的依赖后, 首先 flow-typed update -l ../ 一下, 再将安装后的 npm 包覆盖掉 flow-typed 里面的 npm 包