老板:你来弄个团队代码提交规范
原创- 2024-10-11 17:00:00
- 348
本篇目录
大家好,我是陈哥,今天聊聊禅道的代码提交规范~
背景
在 《还不知道这个原则的程序员,要小心了》的文章中,我提到了禅道的代码提交规范。简单来说,我们将工具融入到禅道团队的日常代码提交过程中,利用工具对流程、行为进行规范和约束。
接下来,我将从编码规范、测试规范等方面,和大家简单分享一下禅道团队的代码提交规范。为了方便大家了解和学习,大家可以扫码发送【代码提交规范】,免费领取禅道团队的代码提交规范。
一、编码规范
禅道团队规定: 开发人员每次本地提交(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仓库本地分支规范、标签命名规范等内容,我已经帮大家整理在文档中,大家可以添加阿道, 备注【代码提交规范】即可免费领取。
希望我的分享可以帮助到你,也欢迎给我留言与我讨论。