前端 Code Review 真的很难推行吗？

这是我昨天晚上刷知乎时看到的一个问题，前端 Code Review 真的很难推行吗？

虽然我简单的回答了一下，但是觉得这个问题可以说得更多。所以就趁着周末，写一篇文章吧。

这个问题其实分为两个小问题：

• 如何推动 Code Review？
• 如何实施 Code Review？

当然，就如同我在知乎里回答问题时所设立的前提一样：只说创业公司和小团队。 一个原因是我确实只在创业公司和小团队呆过，另一个原因是符合题主的提问。 不过，最重要的原因是：创业公司和小团队会给 Code Review 带来的影响。 有哪些影响呢：

• 创业公司：业务快速迭代，需求多，工期少；
• 小团队：人手不足，可能会存在人员水平不同的情况；

结果呢：

• 没有 Code Review 意识，只要代码能跑，没 Bug 就行；
• 代码质量不高，包括老代码和新代码；
• Review 效果不好，Review 前后没有差别；

推动

不光是 Code Review，学会如何推动事情是很重要的。

最直接且最坏的办法就是：找 Leader 求支持。 为什么这样说：如果 Leader 不支持，那直接 GG；如果 Leader 支持，那么完美。

我认为最好的办法就是自己把脏活累活干完，让小伙伴短时间内无痛转换。

对于 Code Review 来讲就是把以下事情统统搞定：

• 对比各种 Code Review 工具；
• 写关于 IDE 插件配置，SublimeText、Atom、VSCode、WebStorm 等；
• 找规范，看规则，写代码风格和代码规范；
• 制定 Code Review 流程；
• 开培训讲座，扫盲；
• 找志同道合的小伙伴，制造舆论；

但是这个办法很笨，要付出很多时间和精力。举例来说， ESLint 那么多的规则，不求全部过一遍，但求心里有数。 至少能够在使用 ESLint 的过程中迅速解决小伙伴们的疑问。

事情推不起来，就是没人支持，即使这个事情是好事。人都是有惰性的。 我们做了这么多事情就是为了获得大家的支持。有点脑子的人都知道的 Code Review 的好处，只不过他们不愿意做罢了。

我在故意没有提“前端”，因为“推动 Code Review”这件事和前端不前端没关系。

实施

把握几个原则：

• 能用工具解决，就不要靠肉眼。代码风格，比如：缩进、花括号；
• 尽可能的消灭异端；
• 找现阶段能够给到最好的解决办法，不求完美的解决办法；
• 新代码严格要求，老代码逐步修改；
• 不要懈怠；

最最重要的是：提高自身水平，多看书，多思考怎么才能写出更好的代码。 多看些关于 “Bad Small Code”，和 “Best Practice” 的文章。 当你看自己写的老代码很屎的时候，这意味着你成长了。

参考

这些文章或者链接都是我觉得很好的：

• https://zhuanlan.zhihu.com/p/21807979
• https://www.zhihu.com/question/41089988

可能我这篇都是瞎扯。

以上。