推荐针对PR，做代码检查，保障入库代码质量。基于PR做事情是我比较看好的，因为这是调动所有研发力量，天然契合的地方。且进一步讲，这也是测试基础设施更能体现价值的地方。
目前Github上有很多这方面的集成系统做的都比较好，能够快速的帮我们落地PR测的检查，比如Travis, Circle CI等。另外就是著名的Kubernetes社区，也自行构建了强大的Prow系统，其不光是基于CICD系统，还构建了chat ops模式，为参与Kubernetes的社区的贡献者提供了方便。
细看Kubernetes库，会发现，其会针对每个PR都做如下静态检查:
gofmt： https://github.com/kubernetes/kubernetes/blob/master/hack/verify-gofmt.sh
govet: https://github.com/kubernetes/kubernetes/blob/master/hack/make-rules/vet.sh
golint: https://github.com/kubernetes/kubernetes/blob/master/hack/verify-golint.sh
因为golint只是纠正代码风格，并不是强制，所以k8s官方就弄了比较软的方案，对于当前已经存在的代码如果有问题，先排除掉(如下)。对于新生代码，如果检查失败，ci就挂掉。
https://github.com/kubernetes/kubernetes/blob/master/hack/.golint_failures
Kubernetes只利用了官方的几款工具, 在检测准确性上比较有保障。有了这些检查点，也能倒逼研发人员关注提交代码的质量，会迫使其在本地或者IDE上就配置好检查，确保每次提交的PR都能通过检查，不浪费CI资源。这也是合格工程师的基本要求。
总结高质量的代码是业务质量保障的基础。而编写高质量的代码是技术问题，同时也应该是企业文化问题。因为当大家都开始注重技术，注重代码质量时，自然会朝着精益求精的路上行进，视糟糕的代码为仇寇。
我的一位老板跟我说过，要做就做Number One。而在没达到第一的时候，那就要向业界标杆看齐，比如Netflix，Google，Facebook等。当大家都非常注重自己代码质量时，工程师才有时间去关注解决更加系统性的问题，而不用一直在Low Level徘徊。笔者深以为然。
Contact me?Email: jinsdu@outlook.com
Blog:
Github: https://github.com/CarlJi