回答问题系列。

code review我目前有两种方法。

一个是直接在网页里看diff（比如github的PR），这样的好处是能够快速了解代码变更，review效率更高，但是很可能发现不了一些全局性的问题（比如重载过多可以合并，或者可以直接复用某些旧代码之类）。

另一种是在ide里把新的代码checkout出来，顺着逻辑重新读一遍，这样的好处是能够完整的评估新的代码是否有问题，但代价是review效率可能很低。

无论哪一种，都需要逐字逐句的读代码，并且要站在开发者的角度重新梳理逻辑，确实非常累（我一天能够review的代码行数撑破天也到不了1000行）。

我也经常遇到review的时候无法达成一致的情况，甚至跟我一个level的人互相review也会有技术理念上的冲突（比如某个设计是不是过早优化、某个功能是不是存在风险之类），这不是问题，review的目标并不是指出对方的错误，而是最终能互相了解各自的想法。因此review的时候如果遇到了无法达成一致的情况，大概至少需要三个步骤：

1. 各自表达自己的观点，这里有个坑就是大部分人对于其他人的观点会有抵制心态，有可能他反对了半天都不知道他在反对什么。因此建议提出review意见的人先描述一遍对方的观点之后，再提出自己的观点
2. 各自提出自己的论据（之前的观点是否有理论、实践支撑）
3. 达成某种共识

一般实践下来，大概会有三种共识：

1. A说服B，直接改
2. 谁也说服不了谁，达成某种妥协（比如我和团队里的同学在某个写法始终不能达成一致的情况下，因为我是业务负责人，因此关键服务必须按我的写法修改，非核心服务可以按他的想法实现）
3. 找其他人仲裁

另外，关于问题里说的，如果只是简单的看了一下之后给了个简单的建议，并且发现他想要的跟你想要的不一样。

你见过哪个产品产品经理有按期上线的一句话需求么……？