要，一定要搞。
这事儿不分公司大小，哪怕就俩程序员，都应该搞。很多人觉得代码审查（Code Review）是耽误时间，是找茬，其实完全不是。我给你打个最简单的比方：
你写了一篇很重要的报告，准备发给大老板。在点“发送”之前，你是不是会找个信得过的同事帮你读一遍？让他看看有没有错别字，有没有语句不通顺的地方，有没有哪个数据搞错了？
代码审查，干的就是这个事。只不过“报告”换成了“代码”，“老板”换成了“用户”。
这么做有几个立竿见影的好处：
-
提前发现问题，成本最低。 一个bug，如果在代码刚写完的时候就被同事发现了，改起来可能就几分钟。但如果这个bug没被发现，跟着产品上线了，让用户碰到了，那代价就大了。轻则用户骂娘，重则公司赔钱。到时候你再回头去改，要重新熟悉逻辑、测试、发布，一套流程下来，半天一天就没了。哪个成本高，一目了然。就算是经验再丰富的大神，也难免有疏忽的时候，多一双眼睛盯着总没错。
-
知识共享，防止有人“不可替代”。 创业公司最怕啥？最怕某个模块只有一个人懂，这个人一休假、一离职，这块业务就瘫了，没人敢动。代码审查能极大地缓解这个问题。A写的代码，B来审查，B就算不写这块业务，看多了也知道这里面大概是个什么逻辑。反过来也一样。大家互相看代码，整个团队的技术水平和对项目的理解程度都会慢慢被拉齐，不会出现“知识孤岛”。
-
统一代码风格，方便维护。 想象一下，一个项目里，有的人喜欢这么写，有的人喜欢那么写，代码风格乱七八糟。过半年，你再回来看自己写的代码，可能都得愣半天。更别说去维护别人写的“天书”了。代码审查可以强制大家遵循一个统一的规范，让代码变得像是一个人写出来的。这样的代码，谁来接手都轻松，可读性和可维护性会高很多。
-
促进沟通和成长。 审查的过程，其实也是一个技术交流的过程。你能看到别人是怎么解决问题的，别人也能给你提出改进建议。对于新人来说，这是最快的成长方式之一；对于老人来说，也能避免闭门造车。
至于很多人担心的“拖慢开发进度”：
短期看，确实是增加了一个环节。但长期看，它帮你省下了大量改bug、处理线上事故、交接项目的时间。这就像开车，你不能为了快，连刹车和后视镜都拆了。代码审查就是你项目的“刹车”和“后视镜”，它让你开得更稳、更远。
刚开始推行的时候，可能会不习惯，会觉得是“找茬”。所以要建立好规则和心态：对事不对人，目标是把产品做好，而不是证明谁比谁牛。大家都是为了项目好，心态摆正了，这事儿就好办了。