- 主题:各位是从哪里获取code review的动力的？
在商言商，leader也好，平头百姓也好，都在商业框架下运行，按照商业奖惩规则最符合逻辑，虽然听着不是那么高大上。
一般往高大上那个方向说的，是为了鼓励员工奉献。当然奉献也不是什么坏事，在一个正常的公司，多劳多得。
价值观也好，文化也好，KPI/奖惩机制也好，最终目的是为了保证团队/公司的商业成功
【 在 Nineteen 的大作中提到: 】
: KPI 有点儿 low。
: 一般都是全团队轮换做 oncall 吧，不想半夜被 call 起来，别人写的代码最好也上点儿心，很自然...
: 作为 Leader，可以不写代码，但是一定要 review 代码，甚至需要 review 团队成员的 comments，掌握团队第一手信息和能力比什么都重要，哪怕不这样，也得摆出姿态给出明确的价值导向吧。如果不是，贵站标准做法是“留着过年么？”
: ...................
--
修改:z16166 FROM 114.245.195.*
FROM 114.245.195.*
所以，review必须有约束机制，比如不修改不让merge。可以提前约定好，5个人的组必须3个以上同意才可以merge代码，提意见以功能和潜在问题为主，这些意见必须改，coding style意见仅供参考等。
【 在 dpblue 的大作中提到: 】
: 关于你说的“code review是个挑错性质的东西，不怎么受人待见，而且容易起争执”，这个我也想知道大家是怎么解决的。如果代码真的错了还好说，那种改善型的意见，真不知道是该给还是不该给。
: 举一个例子，我同事写了一个client，需要实现isAvailable()，就是去连一下对端服务器，连上了就返回true。
: 他的方法是调用一个取groups的API，这个API会返回属于某个ID的一大堆groups，但问题是这堆groups根本用不上。
: ...................
--
FROM 223.104.39.*
这两个不矛盾
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 建议，不要搞时空不同步的code review，而要搞时空同步的结对编程，俩个人凑在一起同时写一段东西，效果和成本平均下来比code review好些
--
FROM 27.91.71.*
公司里随便搞，反正有测试兜底。
开源项目如果没人认真review，肯定死的很快。
【 在 dpblue 的大作中提到: 】
: 我们组里谁都可以review代码，头儿貌似也不太关心你是否review同事们的代码，所以我平时都只顾着自己手上的活，懒得去review。但感觉这样不太好，请问各位是从哪里获取code review的动力的？
--
FROM 175.42.43.*
我们组6个人，只要一个人review通过就可以merge，像我这种刚来一个多月的整个组最烂的仔review通过也可以
【 在 toutouqi 的大作中提到: 】
: 所以，review必须有约束机制，比如不修改不让merge。可以提前约定好，5个人的组必须3个以上同意才可以merge代码，提意见以功能和潜在问题为主，这些意见必须改，coding style意见仅供参考等。
--
FROM 120.21.71.*
那也比没有review强，起码至少两个人看过代码，即使单人错误率10%，review后bug率也会降低一个数量级，当然，如果reviewer不认真读代码另说。
【 在 dpblue 的大作中提到: 】
: 我们组6个人，只要一个人review通过就可以merge，像我这种刚来一个多月的整个组最烂的仔review通过也可以
:
--
FROM 117.136.38.*
大神组最烂的也是大神
【 在 dpblue (deep blue) 的大作中提到: 】
: 我们组6个人，只要一个人review通过就可以merge，像我这种刚来一个多月的整个组最烂的仔review通过也可以
--
FROM 61.149.143.*
看了这个话题下的讨论之后，觉得我对code review的态度还算比较认真的。。
【 在 dpblue (deep blue) 的大作中提到: 】
: 我们组里谁都可以review代码，头儿貌似也不太关心你是否review同事们的代码，所以我平时都只顾着自己手上的活，懒得去review。但感觉这样不太好，请问各位是从哪里获取code review的动力的？
--
FROM 103.107.216.225
矛盾的啊，pairing成本本来就比review高，如果pairing出来的东西还要在review，成本就上天了
【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: 标 题: Re: 各位是从哪里获取code review的动力的？
: 发信站: 水木社区 (Mon Nov 29 18:27:38 2021), 站内
:
: 这两个不矛盾
:
: 【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: : 建议，不要搞时空不同步的code review，而要搞时空同步的结对编程，俩个人凑在一起同时写一段东西，效果和成本平均下来比code review好些
:
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 27.91.71.*]
--
FROM 123.120.160.*
pairing就两人啊，review可以N个人
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 标 题: Re: 各位是从哪里获取code review的动力的？
: 发信站: 水木社区 (Tue Nov 30 12:06:26 2021), 站内
:
: 矛盾的啊，pairing成本本来就比review高，如果pairing出来的东西还要在review，成本就上天了
:
: 【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: : 标 题: Re: 各位是从哪里获取code review的动力的？
: : 发信站: 水木社区 (Mon Nov 29 18:27:38 2021), 站内
: :
: : 这两个不矛盾
: :
: : 【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: : : 建议，不要搞时空不同步的code review，而要搞时空同步的结对编程，俩个人凑在一起同时写一段东西，效果和成本平均下来比code review好些
: :
: :
: : --
: :
: : ※ 来源:·水木社区 mysmth.net·[FROM: 27.91.71.*]
:
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 123.120.160.*]
--
FROM 27.91.71.*