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

背景

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

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

一、编码规范

禅道团队规定：开发人员每次本地提交（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 仓库本地分支规范、标签命名规范等内容，我已经帮大家整理在文档中，大家可以备注【代码提交规范】即可免费领取。

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