e******0
发帖数: 291 | 1 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
照着他意思来改不sign off, 从来没有这么纠结过。
以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。 |
p*u
发帖数: 2454 | 2
"不照着他意思来改不sign off"
this is not right
【在 e******0 的大作中提到】
: 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
: 写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
: 照着他意思来改不sign off, 从来没有这么纠结过。
: 以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
: 怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
: structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
: reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。
|
c*******9
发帖数: 9032 | 3 大公司吧。
【在 e******0 的大作中提到】
: 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
: 写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
: 照着他意思来改不sign off, 从来没有这么纠结过。
: 以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
: 怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
: structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
: reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。
|
e******0
发帖数: 291 | 4 你说他不sign off, 严格来说也不是，有些东西争论起来就是没答案的，谁也不服谁，
然后reviewer就不作为就是了，然后我就得等。。。 蛋疼啊
【在 p*u 的大作中提到】
:
: "不照着他意思来改不sign off"
: this is not right
|
e******0
发帖数: 291 | 5 而且我觉得有的人太过自负personality太强太nerd喜欢干这种事
【在 c*******9 的大作中提到】
: 大公司吧。
|
c*******9
发帖数: 9032 | 6 公司养他们就是干这个的，不然会失业，多体谅吧。我以前老板当着一个测试的面，开
玩笑对我说好好干不出bug，测试人员就都不需要了。结果这位测试拼命挑我的毛病，
事后对我说是不得已，老公失业，就靠她养家。
，
【在 e******0 的大作中提到】
: 而且我觉得有的人太过自负personality太强太nerd喜欢干这种事
|
g*****y
发帖数: 7271 | 7 Do review half day before deadline. Then, everyone signs it quickly.
【在 e******0 的大作中提到】
: 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
: 写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
: 照着他意思来改不sign off, 从来没有这么纠结过。
: 以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
: 怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
: structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
: reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。
|
g*****g
发帖数: 34805 | 8 我老认为，产品环境的hotfix，code review有必要。其他时候与其折腾这个，还不如
逼迫你提高test coverage呢。当然你要是一个bug要真的死人是另一回事。
【在 e******0 的大作中提到】
: 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
: 写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
: 照着他意思来改不sign off, 从来没有这么纠结过。
: 以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
: 怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
: structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
: reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。
|
d*******r
发帖数: 3299 | 9 我觉得 code review 能发现一些菜鸟的低级问题还是很有用的。
最近review公司同事的TCP socket代码，他居然是把 TCP socket 当 message service
(not byte stream service)来用的，每次就socket.recv()一次，就assume把对面整
个的message接收完了，连buffering&framing都不做。这code已经在production里面跑
了一会儿了，我review完让他改，他还说不知道真的是不是问题，汗死我了... 现在网
络条件真是好呀，这样跑着都没出大问题。 |
t**r
发帖数: 3428 | 10 太正常了 多交流 自己也能提高
★ 发自iPhone App: ChineseWeb 8.6
【在 e******0 的大作中提到】
: 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
: 写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
: 照着他意思来改不sign off, 从来没有这么纠结过。
: 以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
: 怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
: structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
: reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。
|
|
|
g*****g
发帖数: 34805 | 11 不是网络的问题，是你 message小
service
【在 d*******r 的大作中提到】
: 我觉得 code review 能发现一些菜鸟的低级问题还是很有用的。
: 最近review公司同事的TCP socket代码，他居然是把 TCP socket 当 message service
: (not byte stream service)来用的，每次就socket.recv()一次，就assume把对面整
: 个的message接收完了，连buffering&framing都不做。这code已经在production里面跑
: 了一会儿了，我review完让他改，他还说不知道真的是不是问题，汗死我了... 现在网
: 络条件真是好呀，这样跑着都没出大问题。
|
h*****a
发帖数: 1718 | 12 Show your backbone and say NO to them.
【在 e******0 的大作中提到】
: 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
: 写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
: 照着他意思来改不sign off, 从来没有这么纠结过。
: 以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
: 怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
: structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
: reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。
|
r****y
发帖数: 26819 | 13 很正常啊，新人嘛，代码的习气被修理是很正常的。学习和交流的好机会。
【在 e******0 的大作中提到】
: 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
: 写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
: 照着他意思来改不sign off, 从来没有这么纠结过。
: 以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
: 怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
: structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
: reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。
|
r****y
发帖数: 26819 | 14 test coverage是必需的硬指标，review是人工的软指标，比硬指标更见功底。
【在 g*****g 的大作中提到】
: 我老认为，产品环境的hotfix，code review有必要。其他时候与其折腾这个，还不如
: 逼迫你提高test coverage呢。当然你要是一个bug要真的死人是另一回事。
|
r****y
发帖数: 26819 | 15 这要看环境，有的组就是按章办事，过不了就拖到下个sprint。不赶进度。赶进度不体
面。
【在 g*****y 的大作中提到】
: Do review half day before deadline. Then, everyone signs it quickly.
|
d*******r
发帖数: 3299 | 16 我们传的 1024 左右 bytes 的 message，也不小了，
我住过的美国 Apartments, 设置 Xbox 测试 MTU/MSS 的结果一般是 1500/1460 bytes，
比 1024稍大。但是如果你Google MSS, 也有说不少是 500 bytes 左右的 MSS.
对于传给 TCP socket 的 message，只要 TCP 自己做了分包分出了更小的 TCP
segments，
然后这些 segments 在中间网络经历的延迟不一样，
socket receiver 方一个 recv() call 就容易收不到完整 message.
当然还有其他原因，也会导致receiver方一个 recv() call 收不到完整 message.
【在 g*****g 的大作中提到】
: 不是网络的问题，是你 message小
:
: service
|
B********e
发帖数: 1062 | 17 挺过去就好了
【在 e******0 的大作中提到】
: 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
: 写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
: 照着他意思来改不sign off, 从来没有这么纠结过。
: 以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
: 怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
: structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
: reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。
|
S*A
发帖数: 7142 | 18 你这个实际情况还真不容易碰到收不全的。
因为你的 1024 小于一般以太网的最大包的大小，
就是你测的 1500。中间的路由器没有神魔事情不
会乱切你的包的。到接受方的 OS 也不会去没事
去切分你的包。相反，OS 缺省配置会合并你的包，
不会每个 packet 都返回给用户的，这样系统调用
的次数太多。所以一般跑起来都没有事。
我的猜想是你要是 1024 大小，每次来回应对，
实际测跑出个不完整的接受很困难。
当然程序还是不应该有这个 bug。
bytes，
【在 d*******r 的大作中提到】
: 我们传的 1024 左右 bytes 的 message，也不小了，
: 我住过的美国 Apartments, 设置 Xbox 测试 MTU/MSS 的结果一般是 1500/1460 bytes，
: 比 1024稍大。但是如果你Google MSS, 也有说不少是 500 bytes 左右的 MSS.
: 对于传给 TCP socket 的 message，只要 TCP 自己做了分包分出了更小的 TCP
: segments，
: 然后这些 segments 在中间网络经历的延迟不一样，
: socket receiver 方一个 recv() call 就容易收不到完整 message.
: 当然还有其他原因，也会导致receiver方一个 recv() call 收不到完整 message.
|
l***e
发帖数: 450 | 19 this can be very frustrating.
when it happens, take it positively, argue with them and you might learn
something through the process. when it deadlocks, team lead/manager will
step in to arbitrate.
from previous experience, if this happens quite often for no obvious right
or wrong, then folks start leaving the group and go somewhere else with less
frustration.
this is most seen for whites with some coding skills. |
d*******r
发帖数: 3299 | 20 你说的对，大多数情况是 1500, 所以没啥问题，但是我感觉还是不是 100% 保险
The MSS that is chosen is the smaller of the values provided by the two ends
. If one endpoint does not provide its MSS, then 536 bytes is assumed, which
is bad for performance.
http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?top
对了，你 SSA 的 C10M 系列进行到哪里了? :)
【在 S*A 的大作中提到】
: 你这个实际情况还真不容易碰到收不全的。
: 因为你的 1024 小于一般以太网的最大包的大小，
: 就是你测的 1500。中间的路由器没有神魔事情不
: 会乱切你的包的。到接受方的 OS 也不会去没事
: 去切分你的包。相反，OS 缺省配置会合并你的包，
: 不会每个 packet 都返回给用户的，这样系统调用
: 的次数太多。所以一般跑起来都没有事。
: 我的猜想是你要是 1024 大小，每次来回应对，
: 实际测跑出个不完整的接受很困难。
: 当然程序还是不应该有这个 bug。
|
|
|
c********d
发帖数: 11593 | 21 谢天谢地这种活宝我只遇到过一次，是别的组的一个东欧人，做的东西跟我们组有一点
交叉。有一次修bug千不合万不合叫他看，过程简直痛苦到极点。那厮不同意我的解决
方案也就罢了，最可恨的是他提出的每种方案我都试过，发现都根本行不通。基本上就
是他提一种我按着试一种，发现行不通掉头去找他，然后他再提一种新的，死活就是不
让我用我自己那种明明可以解决问题的办法。我在被他拖了两周之后终于忍无可忍，跑
去找我的manager说我有一个非技术性问题需要你帮助，现在某人死活不让我check in
，但是他提出的方案又全部都不能用，现在组里还有好几位修的bug需要在我的fix的基
础上完成，再不check in还会有两三个人的进度受影响。于是manager开了个会，叫上
组里几位分量最重的大佬和那一位，一番讨论之后确定了一个新的折衷方案，我按着方
案这个花了一天写好，又三请四催了他好几天他才不情不愿地sign off还说反正这是你
们的module出了毛病我不管。
后来再修类似的bug，我在发review request时果断跳过这位仁兄，专找好说话或者虽
然严格但是严格得有理的大佬。这些人只要开始看，基本上一两天之内就能check in。
某些人惹不起我还躲不起么？
【在 e******0 的大作中提到】
: 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
: 写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
: 照着他意思来改不sign off, 从来没有这么纠结过。
: 以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
: 怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
: structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
: reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。
|
c*****a
发帖数: 808 | |
c********w
发帖数: 308 | 23 code review严格好啊。数据结构的选择，循环的使用这都很重要，不然面试的时候为
什么总是考这些。有review才能学到东西，你自己闷头写对技术的提高有限。当然也需
要有个tie breaker和time bounded。这些都是很基本的。我之前的组review就很严格
，但很有效率，经常大家会积极参与，热烈讨论，互相学到很多。当然也有争执不下的
时候，最后少数服从多数。大家都知道this is business,not personal.
【在 e******0 的大作中提到】
: 新进的这家公司这个组搞code review真的是要把我折磨疯了，review的时间永远比我
: 写代码的时间长。 关键组里有那么几个纠结的闲人， 居然什么细节都仔细去看， 不
: 照着他意思来改不sign off, 从来没有这么纠结过。
: 以前公司review就是大致看看有没有明显的问题，在不在框架设计的范围内，然后具体
: 怎么实现的，没人管你。 现在这帮人，我用set还是array他们要管，我用什么data
: structure他们要管，我用几个循环他们都管！！！ 关键我每次review的时候,几个
: reviewer的意见还不统一，各有各的观点，拖特别长时间，疯了。。。
|
p*****3
发帖数: 488 | 24
刚开始还写很全的Unit test, 和可以automatic的integration test.
现在逻辑不复杂的code也不写unit test了，Integration test也都是manual的，时间
紧，需求也不是一开始就很明确，特别是必须要限时解决的production fix, 测试和
debug基本靠自己的脑子而不是流程，自己觉得合适就可以了，没办法，条件不允许，
能跑最重要。
【在 r****y 的大作中提到】
: test coverage是必需的硬指标，review是人工的软指标，比硬指标更见功底。
|
d*******r
发帖数: 3299 | 25 太赞同这个了
上面一使劲催活，神马设计啊，流程啊，全都是浮云....!!
【在 p*****3 的大作中提到】
:
: 刚开始还写很全的Unit test, 和可以automatic的integration test.
: 现在逻辑不复杂的code也不写unit test了，Integration test也都是manual的，时间
: 紧，需求也不是一开始就很明确，特别是必须要限时解决的production fix, 测试和
: debug基本靠自己的脑子而不是流程，自己觉得合适就可以了，没办法，条件不允许，
: 能跑最重要。
|
c*******9
发帖数: 9032 | 26 有的小公司经常是这样，想学大公司的严谨，却没有大公司那样的资源。
【在 p*****3 的大作中提到】
:
: 刚开始还写很全的Unit test, 和可以automatic的integration test.
: 现在逻辑不复杂的code也不写unit test了，Integration test也都是manual的，时间
: 紧，需求也不是一开始就很明确，特别是必须要限时解决的production fix, 测试和
: debug基本靠自己的脑子而不是流程，自己觉得合适就可以了，没办法，条件不允许，
: 能跑最重要。
|
z****e
发帖数: 54598 | 27 这不是很正常的事情么？
你没有被其他人的代码恶心过
那不算有经验
为什么我们喜欢java
那就是因为java代码通俗易懂，trick少
尼玛，其他语言，我操
看了直接骂娘
当然java代码也有让人骂娘的
但是相比之下，好太多了，我遇到java的难题
最多最多，给我一周，我有信心搞定
其他语言，我绝对不敢保证，尤其是scala
看那个paul吐槽，44个月才tmd回答出一个文档中明显的错误
ur time has no value |
z****e
发帖数: 54598 | 28 所以说，软件工程里面有一个常识很重要
前期投入一定要大，不要急着写代码
否则后患无穷，可以直接造成项目失败
实际上绝大多数失败的项目都是这个原因
这个常识写在所有软件工程教材的前两章里面
现实中你会惊讶的发现，绝大多数人其实不懂这个常识
【在 d*******r 的大作中提到】
: 太赞同这个了
: 上面一使劲催活，神马设计啊，流程啊，全都是浮云....!!
|
f*l
发帖数: 161 | 29 我以前一个组的老中，review相当的挑，基本我的每次都被要求该好几次，比如命名，
位置，还有许多细节。倒不算故意挑，他就要保持他的风格。一个好处是这块代码维护
的很好，可是效率很低。后来新项目来了，一堆人介入，很多人就敷衍下次改，结果再
也不改。因为进度原因，他只会屈服，最终他彻底失去控制。当然后来代码也很难看 |
A*****i
发帖数: 3587 | 30 代码格式直接上lint不就完了？
code review一般只cover一些test不到的地方就行了
不过承认大公司有的code review简直就是奇葩，有时候一条错误的标准被沿用下来都
没人觉得是错的 |
