聊聊SwiftLint在团队的实践

大约在两年之前写过一篇关于SwiftLint的文章，时过境迁不得不说当时的想法还是很粗糙的，但至少也给了自己一个启蒙。过去的一年，公司开始自建中心化的CI，也推广到了各个团队中去，参与其中也是获益匪浅。Lint作为CI中的重要的一环自然也有不少的价值输出，但是随着日常深入的应用还是让我又思考了一下关于Lint在公司团队的实践，也算是对于两年前那篇文章的补充和拓展吧。

（二）缺陷和痛点

成本，不得不说，这是让人使用SwiftLint的最大障碍。

1.主动操作的成本

如果我们直接使用 SwiftLint 的命令行 工具 来进行规范代码，每次都需要我们主动想起“哦~我需要进行一次lint”，然后我执行了一次“SwiftLint”。对于人而言，主动想起的这个操作是非常高的。 产品开发过程中我们总说客户很懒，我们开发人员又何尝不懒呢？

2.构建配置文件的成本

如果我们真的使用 SwiftLint ，它作为一个工具一定是大而全的，然而落实到每个技术团队那都是“大清自有国情在”，几乎没有哪个项目愿意全量的使用 SwiftLint 的规则，大多数情况之下我们只想要我们自己所需要的规则。虽然 SwiftLint 支持 通过编辑配置文件的方式来自定义规则，但是对于一个团队来说往往需要同时开发多个工程，倘若每个工程都需要我们编辑一个配置文件，这样机械的劳动想来是没人愿意做的。

3.团队标准化的成本

在团队的维度上来说，我们一定是希望大家使用相同的规范，使得最后提交的代码不至于五花八门。但是也由于 SwiftLint 配置文件的特性，使得我们没有办法通过现有的方式来规范整个团队的代码风格规则。

4.CI的局限

诚然CI可以解决一定的问题，通过CI我们可以构造出一套标准的流程，通过统一的标准来对每一个MR/PR中的代码进行lint校验。然而可惜的是，CI也存在自己的局限性，首先无论怎么通知，这里还是存在人的主动性问题，即便是通过钉钉或者邮件通知了当事人本次的提交存在哪些问题，但是由于人的“惰性”，很可能就会忽略了本次的警告。而且，CI的操作必须在 commit 之后，即便你是一个自驱力极强的人，每次CI报告的规则违反你都会认真修改，但是太多的 code style fixed 还是会污染整个 git 日志。所以CI的延迟性，也是一个无法忽视的弊端。

（三）团队实践：SafeCommit

针对以上的缺陷，我们团队打算构建一个 SafeCommit 工具，在我们的计划中，不光是代码的校验，我们希望把commit的校验也一并做进去，统一化团队的commit风格。

每当我们需要 git commit 的时候，我们通过 git sc 替代。此时 SafeCommit 会对被添加的文件进行lint，如果是swift源文件那么就进行 lint 操作，否则跳过。如果发现当前的文件没有通过 lint ，那么就把结果输出到窗口。

lint通过之后，工具会提示用户选择一个commit的类型，然后输入本次的commit的内容，这样的好处是简化了高频的 git commit -m 'xxxxxxx' ，同时也是格式化commit的message，当查看git log的时候将会非常的工整。

输入了commit的内容之后，本次的提交也就结束了。

哦~对了，也是支持SourceTree等GUI工具。

（四）SafeCommit所解决的问题

被动性

由于 SafeCommit 是通过 git hook 实现的，所以从原来的工程师自己主动调用 lint 的操作变成了提交时的被动 lint ，也算是极大的照顾了工程师们“懒惰”的天性。同时，也是因为通过 git hook 实现，即便之后不使用 git sc 来进行提交，而通过 git commit 的原生命令来提交，也一样会触发代码以及提交信息的 lint （当然这一切的前提是你至少在这个git仓库下运行过一次 git sc ）。

低成本&低侵入

SafeCommit 默认不会对您的仓库做任何的修改，我们也再也不需要烦人的YML配置文件了。我们只需要通过 npm 来安装 SafeCommit ，我们就可以在所有的Swift工程下使用它，比起官方README中提到的使用命令行和在 build phase 里嵌入脚本实在是方便太多。

还有一个减轻成本的地方是，每次提交我们只会对进行了 git add 操作的文件进行 lint 。这样的好处是，一来不会大规模的 lint 造成每次提交缓慢的问题，二来也对没有接入过 lint 的老项目更加的友好，不至于些许的修改就报出大量的警告。

规范化&普适性

由于使用的是统一的 SafeCommit ，所以对于团队的代码风格统一也是简单了许多，只需要配置一份（当然对于大多数团队来说直接使用默认的配置，就可以做到开箱即用）配置文件，就可以在所有的Swift项目下使用。 SafeCommit 也不强依赖其他的IDE，只要你的工程是通过 git 来进行版本控制的，那么就可以使用 SafeCommit 。顺带一提，由于 SafeCommit 的普世的设计，同时也支持 Java CheckStyle ，如果需要其他的语言支持也可以拓展。

（五）SafeCommit没有解决的问题

针对于iOS开发，如果想要实现 eslint 在 vs code 上的即时性表现，暂时没有什么太好的办法，即便是 SwiftLint 官方所说的 build phase 也是需要 build 才能展示，这样尴尬的处境可能只能等苹果官方的Xcode新特性了吧。

（六）简洁和规范的意义

大概从上学的时候就能看到人和人的差别，他们字迹未必好看但下笔一定工整，一笔一划处处用心。本来工整的行文和整齐的排布并不能多得两分，但这份严谨的匠人态度一再让我叹服。

优秀是一种习惯，最后附上一张爱因斯坦的手稿作为结尾，与君共勉。