每一个项目, 都会有自己的一套代码风格规范, 在现代Java 项目的开发中, 在多数情况下, 我们会使用诸如checkstyle 和findBug 之类的自动化检查工具, 来帮助我们检查将要提交的Code, 是否符合项目的统一规范, 同时规避掉一些简单的错误场景.
同时, 我们可能会对代码的单元覆盖率有一个标准, 例如, 笔者所在的项目组, 使用jacoco 来做单元测试覆盖率的检查, 具体的jacoco 覆盖率配置如下:
limit(counter: "LINE", value: "COVEREDRATIO", minimum: "1.0")
limit(counter: "BRANCH", value: "COVEREDRATIO", minimum: "1.0")
limit(counter: "CLASS", value: "COVEREDRATIO", minimum: "1.0")
也许大家看出来了, 覆盖率的要求是100%. 当然, 我们也提供了excludeClasses/excludePackages 来让Dev 可以忽略一些极难进行单元测试的代码.
然后, 我们将所有这些checkstyle, findbug, coverage check 工作, 打包成为gradle 的一个task. 假设命名为check.
�于是, 每次Dev 在commit 代码之前, 需要先在本地运行gradle 的check task, 以保证他的本次代码提交不会break 掉Jenkins (因为Jenkins 会在每次有新的代码提交后, 自动运行gradle 的check task).
敏捷软件开发, 提倡我们要进行小步提交, 也就造成Dev 每天会进行频繁的代码提交. 如果某次提交的时候, 忘记了运行check 命令, 很可能就会将Jenkins 给break 掉. 在严格的代码风格和100%的测试覆盖率要求下, 这种情况还是会偶尔出现的. 连我司代码能力超神的CTO 也未能幸免.
程序员的直觉告诉我们, 凡是重复不变的工作, 都应该交由机器自动化的完成. 于是, 有些同事提出了使用Git Server hook 来替Dev 自动完成check 命令.
首先, 我们来看Git 官方文档中, 关于Git Server hook 的说明:
The pre hooks can exit non-zero at any time to reject the push as well as print an error message back to the client; you can set up a push policy that’s as complex as you wish.
也就是说, 我们可以使用pre hook 来在制定push 策略, 对于不符合策略的提交, 直接reject.
所以, **我们可以在push 策略中运行gradle 的check task. 如果失败了就reject 本次提交. **
但是, 关于这种方案, 引发了一场争辩. 主要是以下两种观点:
- 机械式的重复工作, 应该由机器来自动执行.
- 这样减少了Dev 的麻烦, 让Dev 的工作�流程中少了一个概念.
- 避免了出错的可能, 这样会使得Jenkins 在gradle 的
checktask 上, 永远不会出错.
- Dev 应该清楚自己在做什么, 和自己应该承担的责任.
- 提交代码之前, 运行
checktask, 应该是Dev 开发流程中的一�个步骤. - Dev 由于知道有这么一个步骤, 会在写代码时, 越发养成更好的风格和习惯.
- 甚至, 有同事提交代码前
check这件事情, 拔高到了职业道德的高度.
这次争论, 到最后也没有任何一方完全的说服了另一方.
元芳, 你怎么看?
