BACK
关于团队协作的一些看法
3 min read
View
我们希望每个人都能自觉遵守约定,对写过的代码负责。
对于一个团队,总有新人加入。开发久了也总有疏忽的时候,由于疏忽造成的影响可大可小,所以我们期望把类似问题出现几率降到最低,所以使用一些约定工具,减少错误。使用自动化集成测试工具,把一些构建和跑测试用例等重复工作交给机器。
- 期望产出风格一致的代码,需要工具约定,可以有几个阶段,根据实际情况选择
- 期望已有模块修改其他模块不会收到牵连,需要编写测试用例,确保期望输出
- 有了测试用例,如果每次都手动跑一遍,这是很繁琐的事情,所以交给持续集成( CI )工具
需要 3 个约定来确保产品的质量
- 统一的代码风格,统一开发环境,统一编辑器配置,可以在开发过程中,减少很多后续维护的问题
- 编写测试用例,开发完成只是第一步,还需要有完整的测试用例来确保模块改动后的正确性
- 持续集成,编写完测试用例后,更需要一个环境自动编译构建测试用例的正确性
-
ESLint,
- 在编辑器中使用提示功能,自觉遵守约定 (阶段一)
- 项目入口处启用 ESLint,强制遵守约定 (阶段二)
- 使用 Husky 之类的提交前格式化工具,但是会让人写代码越来越随意 (阶段三)
- 使用 jest 编写测试用例
- 持续集成工具很多,在 GitHub App 中可以选择,这里选择 travis ci,隐私业务库需要搭建内置环境
参考