老板：你来弄个团队代码提交规范

大家好，我是陈哥，今天聊聊禅道的代码提交规范~

背景

在《还不知道这个原则的程序员，要小心了》 的文章中，我提到了禅道的代码提交规范。简单来说，我们将工具融入到禅道团队的日常代码提交过程中，利用工具对流程、行为进行规范和约束。

接下来，我将从编码规范、测试规范等方面，和大家简单分享一下禅道团队的代码提交规范。为了方便大家了解和学习，大家可以发送【代码提交规范】，免费领取禅道团队的代码提交规范。

一、编码规范

禅道团队规定： 开发人员每次本地提交（commit）时，变更行数不能超过 20 行。因此，大家一般采取小批量、多频次的方式提交。我们希望通过这种渐进式的代码改动，逐渐提高团队对代码提交规范的意识。

然而，在实际过程中，仅依赖团队成员的自觉性是远远不够的。因此，引入工具变得尤为重要，我们使用的是在自主研发的 DevOps 平台。我们在 DevOps 平台上增加了门禁。每当团队成员在本地进行 commit 操作时，就会触发 hook，会对当前的代码进行 diff 检查。

如果变更的代码超过 20 行，团队成员的代码将无法 commit。但如果某个开发人员变更了 30 行，然后又删掉了 10 行，那这次修改就算作 20 行。通过 DevOps 平台这类工具的硬性限制，禅道团队才能做好监督和约束。

此外， 团队成员在 push 代码时，禅道团队要求一次推送不超过 60 行， 结合前面提到的 commit 约束，也就是说每次推送不能超过 3 次提交。代码推送后，并不会存入代码库，而是发起代码评审（类似 Gerrit）。人工评审通过后，代码才能保存到代码仓库中，与其他人的代码进行合并。这种方式适合主干开发，或者对代码质量有严格要求的团队。

其实，禅道团队的做法与 GitHub、 GitLab 的流程有一定出入。GitHub 是以 PR（Pull Request）的方式来确保代码质量，但这种方式并不符合企业的实际流程要求，涉及过多的库 过多会花费较大精力。而 GitLab 是通多分支合并的方式实现代码评审，而我们会强制做事前代码评审，代码评审不通过就不入库。

在后续的研发管理中，我们还会考虑增加代码的覆盖率等要求，来不断完善和覆盖研发管理流程。

禅道代码提交规范

二、 测试驱动开发

禅道团队也曾做过 TDD（测试驱动开发），在相当长的一段时间内，团队进行了大规模地单元测试补充。尽管最终全部补上了，但在此过程中，大家依旧没有形成一种自发自觉的习惯。

《勤训》写道：“无如人之常情，恶劳而好逸。”从人性的角度来说，人都是有惰性的。这种情况下，我们就必须要通过工具来强制规范大家的行为，达到提升效能的目的。

目前，我们通过工具强制执行单元测试：只有通过单元测试，代码才能提交。这包括小批次提交、强制性人工代码评审、强制性的调用本地测试代码检查等。

以禅道项目管理软件为例：

1. 集成了 Git、Subversion、GitFox 代码库，团队能够直接浏览和评审代码并针对代码提交任务或 Bug，直接从代码层面跟进需求进度；

2. 集成了 GitLab 服务，GitLab 用户关联禅道用户，关联 issue 到需求、任务、Bug、提交合并请求。

3. 集成了 Jenkins 服务，创建 Jenkins 构建任务，通过流水线进行自动构建，实现持续集成；

4. 支持 SonarQube 项目的维护和管理，在禅道中可以创建构建任务，并查看检查报告，让代码检测和问题管理更加高效便捷。

此外，我们还会强制性设计评审等流程。设计评审通过引导式表单进行，在后续我们也可能会加入流水线。

禅道代码提交规范

三、 禅道代码提交规范

在之前的开发环境中，禅道团队一直采用 share+vim 的方式。但 vim 对 competitor 的支持相对较弱，如它仅支持编写代码，并没有聊天功能。鉴于此，我们的定制开发部门已切换到具有 WAM 模式的 Visual Studio Code。经过一段时间的试行，我们发现效果还不错。

后续，我们会准备将整个公司都切换成 Visual Studio Code，使用 WAM 模式，充分利用大模型的能力。另外，我们也会将这些集成到 DevOps 的流水线当中，并尝试利用大模型进行初步的代码评审。

总结来说，禅道团队的代码提交流程规范：执行强制性小批量提交，同时进行本地单元测试结果的检查，以及强制性的人工代码评审。实际上，在这之前，我们还存在一个强制性的设计以及设计评审环节。

具体的远程分支规范、Git 仓库本地分支规范、标签命名规范等内容，我已经帮大家整理在文档中，大家可以备注【代码提交规范】即可免费领取。

希望我的分享可以帮助到你，也欢迎给我留言与我讨论。