（一）背景
大约在两年之前写过一篇关于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新特性了吧。
（六）简洁和规范的意义
大概从上学的时候就能看到人和人的差别，他们字迹未必好看但下笔一定工整，一笔一划处处用心。本来工整的行文和整齐的排布并不能多得两分，但这份严谨的匠人态度一再让我叹服。
优秀是一种习惯，最后附上一张爱因斯坦的手稿作为结尾，与君共勉。