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