在项目里形成代码规范并让规范落地是很难的一件事，我想从我的角度分享下我是如何看待落地的~
代码规范落地有三种方法：
- 让人写出符合规范的代码
- 利用 Code Review 反馈
- 利用工具做自动格式化
“写出符合规范的代码意味着什么？”
这是我一直在思考的问题，也是我认为整件事的目标。我可以统计出代码库里符合代码规范的比例有多少，毕竟这是一个可衡量的指标，但我更想知道的是写出符合规范的「背后的人」有多少，这是一个不好衡量的指标，但也更有价值，它可以判断我们的价值观是否得到了大家的认同。
“那么如何让人写出符合规范的代码呢？”
我目前主要用 Code Review 这个工具。我做 Code Owner 时只有一个原则：这个 PR 的内容和我自己提交是一样的。如果我不理解背后的需求，会要求提交者写个说明文档做个清晰的说明，以便了解其目的，从而促进 Review 的有效进行。再者写文档也是重新梳理自己的逻辑的过程（小黄鸭测试法），便于发现自己逻辑上或有漏洞或过于复杂，从而得到调整代码实现的机会。如果我不能保证这个 PR 是安全的，我也会要求除了代码、说明文档以外，还要提供一个测试列表，能列出所有测试过的案例，这样我可以做出更多的测试建议以保证获得足够的安全性，还能顺便培养团队的测试观念。
当然，如果有我觉得要修改的地方，我一般不会只说“此处要如何如何修改”，往往会加上一些目的性的注释，比如“能增加稳定性/内聚性”、“避免无用的重复代码”、“这样写更符合 XXX 规范”等，这个过程能让团队的价值观得以明确。
但是 Code Review 也不是很好的解决方案，它太被动了，还是需要寻找主动出击的机会，如 Code Review Meeting 等。
“为什么不用工具做这些简单的事情？”
其实一点都不简单。自动化工具可以提高流程的效率，减少重复性劳动带来的成本，但当大家还没有形成统一的认识之前，它就不能算重复性劳动，必须直面问题 — “我们是不是正确的传达了我们的价值观？”，寻找技术合伙人、培养技术合伙人是对项目有长期价值的事情，我们不应该用自动化工具隐藏掉“价值观不同”这个事实。只当它变成重复性劳动时，才是引入自动化工具的时机。
“但是这么做会提到大家 Review 的工作量，效率很低”
我们可以想一想做这事的目的是什么~ 是为了追求传播效率吗？想象一下你写了一篇文章，发到技术大群里，它传播的很快，几乎所有人都能看到，但打开看一眼的人会有多少？看完之后认同的人有多少？真正受到影响的人又有多少呢？
不应追求表面上的效率，制定规范是为了在某些方面达成共识，并以此提高协作效率，而不是为了强迫大家写出相同的代码，“我们招的是人而不是一双手”，我们不能只看产出，还要关心人背后的诉求，帮助大家成长也应该是我们的目标。
“可以重点讨论讨论一下如何执行？”
- 成为理解并能正确传达价值观的 Butterfly，以身作则去影响身边的人，写出更多符合规范的代码
- 不要妥协，做难而正确的事