- 主题:各位是从哪里获取code review的动力的？
所以，review必须有约束机制，比如不修改不让merge。可以提前约定好，5个人的组必须3个以上同意才可以merge代码，提意见以功能和潜在问题为主，这些意见必须改，coding style意见仅供参考等。
【 在 dpblue 的大作中提到: 】
: 关于你说的“code review是个挑错性质的东西，不怎么受人待见，而且容易起争执”，这个我也想知道大家是怎么解决的。如果代码真的错了还好说，那种改善型的意见，真不知道是该给还是不该给。
: 举一个例子，我同事写了一个client，需要实现isAvailable()，就是去连一下对端服务器，连上了就返回true。
: 他的方法是调用一个取groups的API，这个API会返回属于某个ID的一大堆groups，但问题是这堆groups根本用不上。
: ...................
--
FROM 223.104.39.*
那也比没有review强，起码至少两个人看过代码，即使单人错误率10%，review后bug率也会降低一个数量级，当然，如果reviewer不认真读代码另说。
【 在 dpblue 的大作中提到: 】
: 我们组6个人，只要一个人review通过就可以merge，像我这种刚来一个多月的整个组最烂的仔review通过也可以
:
--
FROM 117.136.38.*
没见过不代表不可以。步子快，前期review是为了质量，后期发现问题返工合计的工作量可能更大。review比写代码还是要省很多精力的。
【 在 irreallich 的大作中提到: 】
: 三对一review？
: review者承担代码错误责任？
: 你知道这种review的方式，review一个人的代码需要多少工期么？
: ...................
--
FROM 223.104.44.*
显然不是代码越严谨越吃亏，没有人希望大家一起加班发现的bug多数是自己造出来的。
【 在 irreallich 的大作中提到: 】
: 现在很多互联网公司的qa是质量监察部门
: 什么叫监察，我想你肯定明白
: 架子大得很
: ...................
--
FROM 223.104.44.*
贵司的开发模式和评价体系实在不敢苟同。垃圾代码快速上线，然后靠解决问题的数量来获得经理认可，文秘转行的经理也不至于如此吧。
【 在 irreallich 的大作中提到: 】
: 写代码能力强并不一定评级快
: 解决问题的能力强
: 产出高的人才升级快
: ...................
--
FROM 223.104.44.*