现实是 Code Review 只会拖慢项目进度，真正的隐患往往是 Review 之后合并进了主分支，而很久之后才被发现

[zqx]

周五上午我把自己的所有 Bug 修好，提 PR，喊同事 Review (Bitbucket 设置必须有 2 人批准，才能合进发布分支)
然而今天突然被叫起来修 Bug，我想着昨天都搞完了呀。一看是昨天的 PR 还没合并，赶紧再喊同事 Review，这种形式主义的 Code Review 有毛线作用？

[zqx]

我在 PR 阶段被提出的最多问题就是: 变量命名之类的问题。我认为这类属于协作效率问题，不应该在某个具体 bugfix 的 PR 阶段提出，而应该是每周或每月开小组技术会议的时候一起 check。真正应该关注的是: diff 中是否改动了无关代码，改动部分的影响范围，当然还有程序逻辑是否正确，会不会产生更多潜在的 Bug。

[zqx]

Code Review 的好处太多了，但那只有硅谷或者国内小部分工程师文化的公司才能享受，大多数不那么工程师文化的大厂最后演变成了: 上级要求下级 Approve PR，下级一般会假装看代码，然后 Approve ；同级之间 Code Review，就看互相关系好不好，你讨厌一个程序员，那就在他的 PR 中挑毛病吧。

[JamesR]

只能想办法加快审了。
我绝大多数 Bug 都是程序跑上 3 个月以上才能暴露，哈哈。

[Jiavwen]

你每次 PR 是否有足够的测试覆盖？如果没有，那么合并之后出现 bug 也是正常的

[1424659514]

@JamesR 🐂🍺

[zqx]

@Jiavwen 前端，涉及逻辑的部分是有单元测试的，其他 UI 相关的都是人工检查，这部分很难用程序逻辑去描述是否正确

[arrow8899]

只能说明你们 Code Review 没做对，不能说 Code Review 没用； Code Review 是用来改进代码质量和知识分享的，至于代码风格、BUG 等，应该由对应的代码质量检测工具和单元测试来做。

[hoyixi]

Code Review 没问题，而是你们自己特色的 Code Review 有问题

[fonlan]

流程不规范

[kaedea]

平均研发素质不达标的队伍不适合 Code Review，特别是 bat 里的队伍

[jedihy]

代码有 bug 不能怪 CR 的。而且，项目进度问题是你们项目规划本身就做得不好。

[zqx]

各位，我说了 Code Review 是好的，但是多数公司包括大厂也一样，最终会把技术问题演变成流程问题。
关于流程，Git Flow 工作流，双周迭代(固定隔周的星期二发布窗口)，很多项目管理的细节都贴近敏捷软件开发。都是最佳实践啊，哪里出问题了？
我觉得还是人的问题，平均素质差(无论技术上还是价值观上)的即使用了最佳实践，结果也不一定好

[wd]

一把刀拿来杀猪还是削苹果那当然是你们自己的事情，关刀屁事

[justfortest]

Code Review 真的挺难实行的，毕竟不是每个人都对逻辑很清楚，而且很多团队所谓的 Code Review 只是拉几个人开会而已，并不能发现什么问题，作用不大，相比 Code Review 我认为单元测试、集成测试的作用更大。

[zqx]

@wd 在养猪场削苹果和苹果园杀猪，都不合适，大多数公司就是这种环境。

[Antihank]

不 review 的你难以想象你的同事能写出多么愚蠢的代码，做出多么臃肿的设计。

[razertory]

Code Review 有时候需要一定程度配合 Unit Test

[seki]

ui 相关的当然可以自动测啊，e2e，image diff 之类的，有总好过没有

[xiubin]

当需求都写不完的时候,不计入工时的 CR 都是耍流氓

最多也就是看看命名或者单独的方法内部逻辑

[GoLand]

reviewer 需要有责任心，先理解业务需求是什么，并且尝试理解同事的逻辑，尽量找出逻辑 bug 以及一些代码层面的 bug。反正我 review 同事 PR 的时候，都把需求当成自己的需求，首先我会想一想同事的实现方式有没有问题，如果是我我会怎么实现，是不是比这个实现方式更好，如果更好那么我会提出来；然后我会详细看 diff，不要吝啬发 comment。

大多数人如果只有自己一个人写代码，没有 review 是很容易出错的，写个 typo 啥的，逻辑进到一个死胡同，是经常的事吧，很多时候自己想半天都没觉得有错，而别人一看就知道有错。