小小初创公司，merge一个PR太难了

想请问大家的公司merge 一个PR的速度？
我就是两行的PR，都能被comment。说说我个人的code review准则以及无法理解的code review comment。


我自己的浅见：

• architecture 宏观的框架一定要对。什么东西在什么folder，什么东西应该在什么file。例如，model不要和 view混在一起。属于model的functionality，不要乱写到view里面。如果是大的project，一般design phase就讨论了，一般在code review阶段，一般没有大问题。
• readability。另外一个新人来了，看你的code，能看懂。例如：命名，长短，不要套娃一下几百几千行。看着就头疼。别人ramp up费劲。
• 不要留out of current PR scope的comment。人家解决的具体是什么问题，就看什么问题。不要延伸。能merge一个，fix一个是一个。
• 说点好话。三人行必有我师。很多时候人家的code，都有值得学习的地儿。谁不喜欢夸夸呢

我讨厌的：

• 吹毛求疵。一个两行的code，都能给我找点茬，留个nit comment。一个push，在要一遍review，这就多长时间过去了？
• 把别的问题和我的PR混为一谈。莫名被扩大scope。这有个问题，一起fix了吧。你这个已经touch了这个了，就fix了吧。感觉这个可能是小公司的问题

一个 comment 而已。尤其是 nit comment，你完全可以私信说为了赶时间，这次先不弄了。

勇敢 say no，其实都是一份工作而已，我个人碰到的一般都不会强行要求

创业公司都是追求速度，市场做起来之后再管tech debt的事，刚开始code review就搞这么麻烦，难不成创始人是🐶家出来的？感觉很奇怪

也取决于你在组里是否获得信任 我们组基本上对accountability高的同事基本review走个过场 如果是新人或者经常搞出事故的组员那review还是很严的 我们是startup

更多的是reviewer的问题吧 一个commit解决一个问题的原则都没有么 再草台也得有个限度吧 就算要你顺便fiz别的问题 那也是下个commit要做的

我司一个pr来来回回弄一两周很正常，纽约中厂。

改完了就好了吧？
多一个来回也就十几分钟？不算啥大事

同意樓上，一般代碼比較禮貌的同事都是review走個過場，如果新來的或者經常出問題會比較嚴格一點

> 留个nit comment
nit 可以直接要求approve，或者有别的approve都不用理，如果提起，那就是他的不是， nit 是绝对nonblocking的

>一个push review一次。
两次就忍了，第二次的话开个会， 明确说明一般comment一次搞完，或者就在会里决定，下一次只有approve 一个选项， 还有下一次就得 报告TL，或者老板， 这种肯定不行。如果允许， 那老板或者tl 有点儿问题， 鸟用没有.  如果这个组呆着有好处就忍着，下次review 坚决不要找事儿多的review code，忍不了也躲不过就挪窝。实在挪不了窝就只好隐忍， 总有一天会盼来这种人走掉或者对team culture 有作为的领导/TL来

匿名用户 发表于 2024-10-28 19:12
> 留个nit comment
nit 可以直接要求approve，或者有别的approve都不用理，如果提起，那就是他的不是， ni ...

这个culture 是CEO开始enforce的极端micromanage，的确只有隐忍和挪窝的选择了