这两个方法不等价啊

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

你同事的方法测试意义大一点。

【 在 dpblue 的大作中提到: 】
: 这个方法就一个简单目的：看对方那个微服务是否可用，返回Boolean
:
--
FROM 175.42.43.*

不是自己到处求别人review自己的pr吗？
不然没法merge啊
【 在 dpblue (deep blue) 的大作中提到: 】
: 我们组里谁都可以review代码，头儿貌似也不太关心你是否review同事们的代码，所以我平时都只顾着自己手上的活，懒得去review。但感觉这样不太好，请问各位是从哪里获取code review的动力的？
--
FROM 113.65.10.*

一般都是事先安排好小弟，无脑approve自己的pr

【 在 keygen (失落灵魂之囚) 的大作中提到: 】
: 不是自己到处求别人review自己的pr吗？
: 不然没法merge啊
--
FROM 27.91.71.*

KPI 有点儿 low。

一般都是全团队轮换做 oncall 吧，不想半夜被 call 起来，别人写的代码最好也上点儿心，很自然...

作为 Leader，可以不写代码，但是一定要 review 代码，甚至需要 review 团队成员的 comments，掌握团队第一手信息和能力比什么都重要，哪怕不这样，也得摆出姿态给出明确的价值导向吧。如果不是，贵站标准做法是“留着过年么？”

【 在 z16166 的大作中提到: 】
: 动力主要来自KPI。。。KPI要求流程里必须有这步，发布出去出了问题可能要担连带责任（主要责任还是写这个代码的）
: code review是个挑错性质的东西，不怎么受人待见，而且容易起争执
: 极少数情况下是为了学习别人的好代码，那种已经不算review了，算learning。
--
FROM 221.216.192.110