求问如何对待吹毛求疵的code reviewer

最近刚转到新组，组里一个待了很久的senior经常对PR吹毛求疵，比如代码里的注释结尾是否打点或者PR的summary都会指出要求改正，这就导致一个PR有很多iteration都还不能merge，就很沮丧。感觉那些都是非常细小的东西。我看他自己的发的很多PR都是非常细节的不影响functionality的感觉可有可无的东西。感觉他就是那种完美主义的人，但是很反感他把自己的preference强加给我。其实改了也无妨，但是真的很影响工作积极性，都不想push 代码了。

请问大家是怎么处理这样的reviewer的？还是我自己有点over react了呢？



补充内容 (2022-05-29 11:43 +8:00):
组里code有专门的的lint工具，每次都是lint之后提交的。最开始他review的时候有些非重要的我ignore了，因为TL approve了，然后merge了代码。他好像觉得很气愤，觉得我没有按照他的来。于是后来他每次review都会block，没有他的批准我的代码即使TL approve都不能merge。

工作久了就会发现这种人真不算啥，工作的一个重要成长就是减少情绪在工作出现。

看公司/team 文化, 如果是个注重 code review 和 code quality 的公司, 感觉有这些很正常吧. 只要不是 错误或者 controversial 的建议, 那都是你学习的机会. code summary 总要写, 就写好呗, 写 comment 就注意 sentence case 呗. 都是好习惯. 直接问 ta 有什么好的 coding best practice 的资料可以学, 你自己先学好做好, 免得提交代码的时候来回 comment 影响时间.

如果你觉得这件事情不对, 那你就提出反对, 说明为什么把 code quality 提到这个程度是不值得的, 你不做好这些能省下多少时间, 提高多少 productivity / 或者对方提出的建议为什么是不对的. 我觉得 engineer 就是讲道理嘛. (如果不讲道理, 针对你啥的, 那你就正式的和 ta 或者 manager 谈)

首先按楼主的描述，对方并不是宽以待已严以律人，行为是一致的，至少说明此人对事不对人，气可以消一半。
另外看其code review的质量，如果总之捡了芝麻丢了西瓜，那的确恼人。但如果对方也能认认真真review提出靠谱的comments, 那这样的reviewer求之不得。

尽量把这个当做学习的机会吧

这些team 的 coding standards 一回生二回熟
前几次commit学好 以后就习惯了
就像interview 一样，从小细节就可以窥看整体的品质！

建立同盟，找自己的同盟review。

+1 工作中也遇到过类似的人，平常吹毛求疵就罢了，有重要的项目ddl的时候每个PR也是这么卡，当时就感觉写code实在太难了。我感觉要跟mgr说，说出自己的想法，然后最好整个team统一一下code style。 可惜我自己之前遇到这样的人在team中是很被mgr认可的，最后说了也没有办法，只有换组/跳槽才解决。 我自己也很好奇这个问题怎么算是最优解。

建议规范化流程，尽量减少个人preference
比如pr summary统一使用一个template
commit message统一使用conventional format

review 会block吗， 还是得找一个宽的组队stamp， 但是这种review 还是有建设性的， 尽量学习一下。
如果一定要这个reviewer approve， 那太官僚了， 搞个会面对面， 把blocking 的讲出来， good to have 的整理一下， 他自己个人偏好的很有礼貌的push back， 问， 这是业界best practice ，一定要这么干还是个人coding style， coding style应该有统一linting 工具，不应该由reviewer 指出。
设计上偏好取决于reviewer 是不是项目负责人， 负责人追求按照自己的理念设计， 你是小兵， 请照做，他不担责任， 礼貌的ignore