管他啥问题，没人背锅不行，哈哈

【 在 xiaoju 的大作中提到: 】
: bug不是个人问题，是系统性问题
:
--
FROM 114.245.195.*

同级别或者同水平的人如果以理服人搞不定，还有争议的话找仲裁，也就是找权威的人来拍板

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

你们俩的实现都很奇葩。。且不说这玩意儿有用没用
即便要做，也应该是让服务端直接写个返回200的空接口专供测试用吧
哪能用业务接口测试去

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

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

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

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

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

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

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


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

嗯，看来以后我要改自己的review习惯了

因为以前是C++码农，眼里容不下任何效率不高的实现


【 在 xunery 的大作中提到: 】
: 个人感觉得原则上这不属于code review该管的范围，当然也分情况。说说我的观点
: 1.code review的目的找错误，明显的不明显的错误。你举例这种如果没有重大影响，编码人员有自己实现的自由。
: 2.如果成员水平差距挺大，应该制定详尽的编码规范，能避免很多类似这样扯皮
: ...................
--
FROM 120.21.44.*