聊聊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新特性了吧。

（六）简洁和规范的意义

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

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