遇上一个对Code Quality 超级执着的组员，快被逼疯了，经验

组里有一个很资深的组员，对code quality超级执着，很害怕code让他review，偷偷问了其它组员，也是同样的感觉，大家代码都不敢给他看。最近一次一个PR，稍微有点大，12个文件，已经改了5，6遍了，跟他单独会议两次了，还是没过，头都大了，快崩溃了。
.--功能开始设计的时候都达成一直了，方向没有问题，但总是卡在code细节上了，总结这些问题包括：
1. 实现方式。
    我有我的实现方式，也有很强的理由，tradeoff也做过分析，但是嘴笨总是说不过他，郁闷。
2. 测试方式。
    测试code本身就是屎山，只能跟着前面的人再堆屎了，然并卵，这位非得要求从现在开始，不能再堆屎了，要从我这里开始开始一点点改变。无奈，他是资深组员，我新来的才刚半年，嘴笨，怎么说服不了。
3. nit, 如命名，格式等。
    我承认应该做的更好，我就好奇, 他眼神儿是怎么练出来的，这么好，有什么好的工具吗，我都用上chatgpt帮命名变量了。还有写现在的代码的时候，我发现前面有个哥们儿多加了了一个不必要的引用，顺手去掉了，这也不行，勒令改回去。。。

我承认如果组里有一位对代码质量要求高的组员对整个组是非常有好处的。但是这么下去我的productivity怎么办，我的feature没办法release了。最近要求尽快出东西，这“多快好省”是不可能同时实现的。大家有没有遇到同样的问题，如何化解...

还有，能吵架是一个巨大的能力，如果嘴上吵不过别人的话，就只好辛苦动手干活了，如何提高吵架的能力？特别是临场反应，有时候临场没想起来，事后反应过来了，憋屈得要死。

补充内容 (2023-03-18 03:30 +8:00):
"还有写现在的代码的时候，我发现前面有个哥们儿多加了了一个不必要的引用，顺手去掉了，这也不行，勒令改回去。。。"

这里违反了“一次改动只针对当前需要”的原则。如果那一行的确需要拿掉，必须重新开始另外一个PR，另外一个目的。
        
         -- 好吧，我承认应该感到庆幸，学到了很多，你也学到了吧！

的确很头疼，这种事情可以找老板聊聊（不是告状那种），问问有什么建议，如果老板和这个人意见不统一的话你老板也可以帮助influence一下

但是话说回来了，如果你还是职场新人的话，应该很庆幸能遇到这种人愿意花时间去扣每个细节，最后获益的其实是你（不耽误你的进度的前提条件下），这种帮别人review代码的事情很多时候都是吃力不讨好，最后这个代码上去了那个人也只是帮着review了并没有什么实际上的功劳呀

你要是说不过他，那么他就是更有道理

我也是嘴笨，英语不好，遇到这种复杂的 argue 我就尽量在 IM 上发消息，像写作文一样把论点列好。 我觉得如果你真的占理的话不应该说不过人家

lz站在对方的角度想想，他跟你耗同样时间，去搞一个不是自己的项目，还不得不看新人的code，他不是更痛苦吗？

怎么会有这么大的 PR，不应该拆开吗？

如果大頭沒意見的話基本沒用
建議LZ針對他所提出的要求總結 以後寫code按照他的pattern走
如果很資深 老闆可能也不想lost他 最後只能照著他的要求
除非他的request endanger team 利益
不然不太會有改變的
所以最後只能LZ改變自己

我们组有个更执着的，5个文件300多条修改意见，改了一周

非原则问题或者两可并且不需要特别巨大的改动的话，建议由着他。毕竟在组里的时间差距会使得即使道理是五五开的情况你也很难说的过他；
. From 1point 3acres bbs如果他的建议有正确性的问题，或者需要比较巨大的/涉及到其他代码的系统性改动，一种选择是在组会的时候提出来或者是拉上某个足以跟这个人制衡的另外的组员甚至老板开小会讨论，看看能不能在另外的code review里面去实现这个改动（顺便自己code review喜加一）
另外一点是，嘴确实是需要练的，怎么写都行大差不差的时候嘴上功夫就能起到决定性作用了

身在福中不知福，LZ应该没怎么接触过正经的开源社区项目，没被要求更严格的社区杠精骂过

1我可以理解，确实没必要一种实现方式，可以跟mgr私聊讲讲，2我觉得可以采纳，不想堆💩是好事，你后面维护也简单
其实有个人真的扣你的代码是有好处的，曾经我很羡慕bf的高质量代码，问怎么学的，他：以前公司曾经有个老英就是一行一行扣，优化和naming到极致好，学了好多东西，现在看下别人代码就知道问题和优化方向

一般公司都有自己要求的代码规范吧，从变量命名到ood设计，甚至tab。短时间是很累，养成习惯了，会提升团队效率，特别是大的code base。