为确保代码质量和效率，确定合适的团队开发流程流程就至关重要了。
开发流程
保证代码质量下限
- 确定代码风格、规范、单测以及 Git 规范
- 制定技术实现文档模板
- 确定团队版本管理策略 thunk-based vs feature branching
- 什么时候需要重构
需求开发流程
- 对需求的思考
- 编写技术实现文档 @审核人 进行技术文档评审
- 根据代码性质决定单测编写范围
- 根据团队版本管理策略进行代码开发
- 完成后 @测试工程师 @ 代码审核人
- 完成代码合并，关闭需求
对需求的思考
- 首先了解为什么要做这个需求，它的背景是什么，能带来多大的价值？
- 这个功能在当前的系统是否已经实现了？如果实现了，是否可以复用，如果不能复用，差别在哪里？
- 这个功能除了满足当前的需求，还可以举一反三用到别处吗，是否可以抽出公用业务组件 / 模块 / 类 / 函数？
- 这个需求是一次性的需求还是长期的，后期会怎么发展？
- 技术上实现的成本高不高，如果高的话，是不是可以选最痛的、优先级最高的做，然后小步迭代？
策略选择
feature branching 适合的场景
- 开源项目
- 你有很多初级开发者
- 你已经有一个成熟的产品，此时你关注的是性能或负载，这种优化需要非常精准的改变，时间不是问题
feature branching 不适合的场景
- 当你项目刚刚开始时
- 你需要快速迭代时
- 当你有很多高级工程师时，你相信你的开发者，它们是专业且负责的
feature branching 存在的问题
- 一个功能，会存在多个分支上，如果要修改点东西，需要知道这个 feature 存在哪几个分支上
- 合并困难，那么多分支，分支到主干、主干到分支，多路双向合并，非常的麻烦
- 单独开发的特性可能会创建长期存在的分支，而这些分支可能很难与主项目结合起来。
thunk-based 开发模式
- 所有开发者直接工作在 master 分支上，可以直接提交代码
- 有些场景，会创建短生命的特性分支，当代码编译和测试通过时，他们可以直接合并到 master，它确保开发是持续的，并防止开发人员创建难以解决的合并冲突
- 在这种方式想要审查代码，那就只能进行完整代码检查，进行需要有些保证代码质量的策略
- 严格的代码风格
- 严格的 lint 校验
thunk-based 适合的场景
- 当你项目刚刚开始，比如需要快速开发一个 mvp 版本
- 你需要快速迭代
- 当你与有经验的工程师合作时，这种模式体验会很棒
thunk-based 不适合的场景
- 开源项目
- 当你有很多初级工程师
- 当你有成熟的场景，或庞大的团队时