个人感觉得原则上这不属于code review该管的范围，当然也分情况。说说我的观点

1.code review的目的找错误，明显的不明显的错误。你举例这种如果没有重大影响，编码人员有自己实现的自由。
2.如果成员水平差距挺大，应该制定详尽的编码规范，能避免很多类似这样扯皮
3.如果出现分歧，必须有能拍板的技术大佬（管理者，架构师）做仲裁。

即使这样，由于编码人员的水平不同，编码认知上还是会有各种分歧。关键性的代码交给水平高的人去实现，团队内部应该定时交流一些代码写法，关于效率，关于命名等等，就是代码规范的交流，不用太久就能使代码看起来像一个人写的一样。

虽然你举例的情况，先假设你说的情况你的方式效率更高（是不是更常规的方法也不一定，也可能另一个另类），但是如果使用场景根本就没有效率的要求，修改已经通过的代码有需要各种测试等的风险，就不如不改。

如果是用在对效率要求非常高的地方，可以把这个实现看作错误，我想他自己也会改的。如果依然不认同，说明把功能给错的负责人，水平不足以负责这么关键的部分。我想大部分都不属于这种情况。其他情况不用太吹毛求疵

内核组和应用组的编码要求是不同的，关键还是看应用场景。尺度由负责人统一规范，而且要提前规定好，不是代码都跑起来了之后。说到底是代码管理问题，不是你一个普通员工的事。技术负责人不负责，就会有各种类似你说的问题，就不要奢望项目代码能好到哪里


【 在 dpblue 的大作中提到: 】
: 关于你说的“code review是个挑错性质的东西，不怎么受人待见，而且容易起争执”，这个我也想知道大家是怎么解决的。如果代码真的错了还好说，那种改善型的意见，真不知道是该给还是不该给。
: 举一个例子，我同事写了一个client，需要实现isAvailable()，就是去连一下对端服务器，连上了就返回true。
: 他的方法是调用一个取groups的API，这个API会返回属于某个ID的一大堆groups，但问题是这堆groups根本用不上。
: ...................
--
FROM 115.171.170.*