为啥需要规范？

  1. 降低新成员融入团队成本，同时也避免挖坑。
  2. 提高开发效率、团队协作效率，降低沟通成功。
  3. 实现代码风格高度统一，方便review,可以提高代码可维护性。
  4. 规范是实现自动化基础。

工作流规范

1.开发规范

  1. 版本规范，大小版本号
  2. 项目分支规范(mastet、dev、hotfix、feature-xxx)
  3. 提交信息规范，不符合规范的代码和git提交信息不能入库。有利于review和自动化生成CHANGELOG

2.构建规范

  1. 约定优先配置。
  2. 方便升级。可以参考vue-cli、create-react-app等等

3.发布工作流规范

  1. 代表变更
  2. 提交代码变更到远程版本库
  3. 程序通过CI(持续集成)测试
  4. 合并到master分支
  5. 生成和提交CHANGELOG
  6. 打上Tag
  7. 推送

4.CD持续交付/部署规范

5.任务管理规范

  1. 看板是目前最为流行的任务管理工具。
  2. 图标类：甘特图。
  3. 工具类：Trello等

技术栈规范

从技术框架角度

  1. 选择成长性的技术框架，要面向未来面向未来。例如选择Vue、React等有大厂支撑、社区的活跃度、开发活跃度。
  2. API稳定。考虑业务升级改造的成本。
  3. 生态系统是否完善。相关的组件是否齐全，社区的开发人员贡献。

从团队角度

  1. 选择团队最熟悉的技术；很好的控制使用过程中的风险，方便对程序进行调优。
  2. 从团体成长角度上看，可以选择新技术。作为leader需要考虑的是：
    1. 学习成本。考虑团队成员的接纳能力。如果成本小于收获的利益，在团队里面推行估计阻力会比较大
    2. 收益。是否能够解决当前的某些痛点
    3. 风险。一般我们不能将一个实验阶段的技术使用的生产环境中

从业务角度

  1. 理解当前的业务，理解用户的需求，当下需要解决的首要问题，以及可能有的风险是那些。
    将目标进行分解，进行具体技术选型、模式设计、架构设计。

项目组织规范

项目组织结构

  1. README.md:
  2. CHANGELOG.md:
  3. package.json:
  4. .gitignore:
  5. .gitattributes: git配置，有一些跨平台差异的行为可能需要在这里配置一下，如换行规则
  6. docs/: 项目的细化文档, 可选.
  7. build: 项目工具类脚本放置在这里，非必须。如果使用统一构建工具，则没有这个目录
  8. dist/: 项目构建结果输出目录
  9. src/: 源代码目录
  10. tests/: 单元测试目录. 按照Jest规范, tests目录通常和被测试的模块在同一个父目录下
  11. envConfig: 环境变量配置

编码规范

1.javascript

  1. 工具：eslint
  2. 规范：业界Airbnb规范
  3. 类型检测：Flow、Typescript(个人推荐)

2.css

  1. 工具：stylelint
  2. 规范： Airbnb css/ Sass Styleguide
  3. 方法论： BEM命名规范

3.html

4.代码格式化

  1. 工具：Prettier,代码格式化都可以交给他。

5.Code Review

  1. code review好处
    1. 让其他成员快速熟悉代码
    2. 让开发者提高自的代码质量
    3. 提高成员的编码质量

文档规范

前后端协作规范

技术沉淀

资料来源于掘金