为什么好多人code review不会一次把comment都写出来

😭 因为每看一遍写出的读后感都是不同的

我向来鼓励一次到两次，下放自由度，信任作者判断但是作者要自己负责。reiew里的 red flag 不应该在review里头来回讨论，发现马上组织讨论，必须做决定，有分歧要么信任作者，重要的扩大会议人数，总之不应该在review 里头讨论好几周，两天comments addressed还没人approve直接approve。

我偶尔会这样，也偶尔会被这样，有各种原因吧，比如发现了比较严重的问题，继续看下去可能没太大意义因为很可能要大改，也有因为改过几轮这轮差不多要approve了所以仔细看了一下细枝末节的问题比如unit test，不能排除有个别人人别有用心，但对这事反感非常大也没什么必要，不如想一想为什么自己的code还是有瑕疵怎么能避免类似问题。

有时候review一眼下去一堆问题，比如明显的debug output哪哪都是，就真的不想看下去了。我觉得作者自己起码得每一行都过一遍，确保没问题再push上去给别人review，这是对别人起码的尊重，这样别人才会尊重你

我也是经常碰到这种烂人。就比如来一个comment 问你这个用了吗。过会再来一个comment说噢没关系看见了。我甚至怀疑他们联合起来想要让我看上去很糟糕。叫我东改西改 说了几十个comment在我的draft PR上。我照做了 最后他自己做了个什么全局的东西 让我把改完的全部删掉用他的。拖了当个礼拜 现在团队都觉得是我慢。

严谨的review程序是每个iteration都要当作新的一样重新过一遍。

我现在有时候会这样：
代码逻辑有问题，觉得别的地方没必要看了，直接把有问题的地方先让他修了。
快下班了/24h快到了，先把重要的几个地方标出来发出去。
Review完自己写代码的时候想到了一些新的地方。
多动症，注意力集中不了了。细枝末节就之后再看。

总结一下主要还是精力不够😅😅😅想用最快的时间结束一轮Review

还有一种可能，是不是你每个change都太大了，reviewer每次都只能看进去一部分？用git或者hg拆成多个小的change，对你对reviewer都好。

从 reviewer 的角度来说，如果这个 CR 太大或者一些地方需要仔细想想，比如我一开始觉得这个地方写的不错，但是在想从其他角度出发会不会换个方法更好，就需要思考时间会晚点写上去。

从代码作者的角度来讲，最好是不着急，就是同时有多个 working threads，然后每天看一次 comment，等评论的时候做做别的工作。还有一个比较有用的建议是和 reviewer 稍微 sync up 一下，确保你们在 high level 上没有分歧，他们也能理解你的代码在干嘛。

如果排除楼主不努力，确实没有注意到的情况，小心这种事儿带来负面反馈。。。。

俺以前的同事做事儿风格有点奇怪，review 两个自己玩去了，接着一会儿回来 review，甚至没看明白瞎评论，如果别人不细看，只是大概看，可能对你的印象不会很好。

如果是后面一种情况，别做软柿子，当着你老板的面问问他啥情况