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

我对第一条实现方式有个经验，在开始动手写代码之前可以先和老员工preview一下，听起来麻烦，但是能很大的提高效率。首先写好代码之后你和他做code review的时候不太会有surprise, 而且一般来说得到资深组员的建议可以少走很多弯路。不同人有自己的风格，如果你是开始写第一行代码前先写个框架的这类人，把design spec和同事沟通一下，一般不会出大问题

1 是真的因为楼主嘴笨还是对方说得更有道理？如果真是嘴笨那组织一下语言comment 回去然后再找对方单独会议怎么样？照着comment说就当是个大纲？

2和3在公司工作很正常吧。同意楼上一层的，每个公司都有自己的代码规范，还是尽快适应好。不然你觉得痛苦，reviewer 其实也很痛苦。我作为reviewer 看到nits 也很痛苦，真的不想comment 但reviewer 也有reviewer 的责任。我有一次就是为了一个bug fix 能快点merge，放水appreove 了我们组的另一个同事的代码，当天就被一个士大夫发现然后教育了。

不过不太理解“前面有个哥们儿多加了了一个不必要的引用，顺手去掉了，这也不行，勒令改回去”。如果真是对代码质量执着的人应该看到这种改动会很高兴吧。

首先，并不知道lz的code quality具体如何。
我只能以我的经验说一下code quality给我造成的职业伤害。
我在两三年前从印度同事的手上接过了一个项目，虽然不能说是屎山，但design和implementation可以说是一塌糊涂。最大的问题如下：
1. 一个相同的复杂逻辑，在不同的地方以类似但不尽相同的方法实现了多次。
2. 各个组件之间严重耦合，A组件只能用于B组件，放到C组件下就得重新写。
3. 组件内部的逻辑严重依赖全局变量，全局变量一改，各个实例都得变。
4. 全局变量没normalize，一个小细节改了，整个全局变量一起改。
5. 命名毫无章法，比如一个接受多个动物的变量名，明明能叫animals，偏要叫animal。甚至animal都不叫，就叫item。
6. 数据结构感人。明明是寻址大大多于排序的变量，非要用链表而不是哈希来实现。

每个问题单独看都不是大问题，但给scalability带来了相当大的难度。我每重构一个组件都要花费跟重新开发组件差不多的时间。有个sprint我就为了重构一个组件，结果改动了一百多个文件，删掉了三千多行代码，增加了两千多行代码（含注释）。

变量名这种小事，一般人家让我改我就批量一改就完了，打嘴仗还不够花时间的呢，根本不去纠结
他是给你提了多少个变量名的问题，还能让你专门写一条出来？

zoevelynne 发表于 2023-3-17 11:23
变量名这种小事，一般人家让我改我就批量一改就完了，打嘴仗还不够花时间的呢，根本不去纠结
他是给你提了 ...

你没遇到过一定要把两个单词的名字改成一句话的。。。在java语法里
class A = new class()
这么一个statement能写三行。。。

感谢楼主提供真实职场故事。
有些人是真的有强迫症，比如有人就真的是不洗澡不会出门。

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

是的 很烦 换组吧

确实是你代码的问题，可以据理力争，该改就改。历史遗留问题，开个ticket去improve，assign给老板去prioritize，link上他即可。

你自己说你刚来半年，而且他不给你approve 你没法ship 那么很简单 , 听他的改就完事了