我现在公司，这点氛围很好。责任感强的人
多了在一起，工作就觉得有意思些
cr，核心是发现瑕疵，而不是挑刺，严禁对人批评。
我们必须要review，但可以是任何人approve，也可以任何人题review意见。

我review得稍慢些，没那么积极，leader和CTO，是重构最多的人了，review也很积极。

核心还是人的因素，前公司，氛围不好，也有review，总在吹毛求疵是不对的。一个pr，只要没有bug，对原代码质量有提高，对功能改进就应该approve，那些拼写错误，指出来就行。




【 在 dpblue 的大作中提到: 】
: 问题：如何给同事做code review同时又不会惹人反感？
: 就像你前面说的，你觉得我说的两个做法都算错，但你楼上认为code review不应该管，也就是说如果是你review他的代码，给了意见说不行，那他一定很不满，心想：”明明不应该管的东西，干嘛非要提，害我没法merge“，这个怎么破？
:
--
FROM 117.136.0.*

为别人的代码bug负责的话
review代码会需要大量的时间
这个都是工作量
会影响正常工期
真要互相review的话
每周至少要花一天时间再这上面

就问项目经理同样不同意
【 在 z16166 的大作中提到: 】
: 开发（包括写代码的、看代码的）、测试，一起为bug负责，不是流行惯例？  
: --  
: 发自xsmth (iOS版)  
: --

发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*

因为互联网思维和敏捷开发流行啊
敏捷开发，互联网思维
1. 先实现功能，后面再优化（将来优化的活也不一定我干，谁干谁倒霉吧）
2. 这套代码上线三天后可能被重构
3. 这个部门搞不好下半年关门
4. 作者搞不好下半年离职

做0-1的吃肉
做1-100的喝汤
快速实现是王道，实现了就升职加薪，后面不干这个了
优化代码是底层，犯得上么
【 在 xeagle 的大作中提到: 】
: 这个观点确实很有代表性“代码能工作，为什么要改呢”。慢慢的，就变成了垃圾场  
:  
: 发自「今日水木 on iOS」  
: --

发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*

三对一review？
review者承担代码错误责任？

你知道这种review的方式，review一个人的代码需要多少工期么？
项目经理同意么？

【 在 toutouqi 的大作中提到: 】
: 所以，review必须有约束机制，比如不修改不让merge。可以提前约定好，5个人的组必须3个以上同意才可以merge代码，提意见以功能和潜在问题为主，这些意见必须改，coding style意见仅供参考等。  
: --

发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*

现在很多互联网公司的qa是质量监察部门
什么叫监察，我想你肯定明白
架子大得很
偶尔出来查一下
出了问题查一下
监管才是主要工作

大多都是程序员自测后直接上线
出了问题大家半夜一起起来查

这种规则下
你代码写的越严谨越吃亏
【 在 cn62 的大作中提到: 】
: 公司里随便搞，反正有测试兜底。  
: 开源项目如果没人认真review，肯定死的很快。  
: --

发自「今日水木 on iPhone 12 mini」
--
FROM 223.72.19.*