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

某大厂， 设计阶段。 不允许太多story/tasks。 然后一个PR 几十个files。 现有的framework、workflow不允许refactor。review周期经常是2-3weeks。不懂其中logic的人们  argue nit/not for 100 times

以前我也觉得烦，现在觉得这种mentor不可多得

真的是好事的，有人愿意很耐心一点点的帮你看code，跟他讨论tradeoff的时候，是一种深入学习的好机会。我刚入行的时候经常会copy/paste，命名不行，然后code 的格式也不够好，我同事能够一眼看出来我哪个地方多了空格，我paste不懂的地方他也能一眼看出来反问我，还提供很多优化的思路。锻炼了两年后，进步很大。
你优化屎山testing的时候，可以在standup上强调自己做的事情很重要，不仅完成了当前任务，还提高了以后代码质量，而且你还可以给那个人credit，感谢他帮你review，你们一起提高整个code base的质量等等。
如果你老板或者别人认为你出活很慢，你可以提出来这个tradeoff，是要更快的产出，还是要更高质量的代码，把问题抛回去，让你们组一起做这个决定。
关于变量名、代码名，我自己非常讨厌起名字，如果我预感到这个名字很重要，别人要求高，我会在写code前就问清楚，把我自己proposal的名字提前发给同事，大家都同意了再开始写

等你后面遇到那种表面笑嘻嘻，反手直接approval，从来不认真review code的senior/staff的时候，就该想念这个老哥了

有次我也碰到一个人review 鸡毛蒜皮一大堆。很花时间。你要说有guide style follow ，那我还是很感激的。他有很多建议是，改顺序，refactor ，等等。
我义正言辞地说，写程序有很多写法。没有说我这个写法比你这个写法差。但是真正非常key useful的改动是别人提出的，不是他。
懂技术的managers 会知道如何处理这种人。但是不懂技术的manager，自己也搞不懂，只能和稀泥。

这个人听起来不是对code quality要求高，是非常nitpicking，这种人就算很senior水平很高合作起来也是很头疼的。从这种人身上其实可以学到很多正面的知识，只是忍一段时间学完之后建议换组，不然每天上班如上坟。别问我怎么知道的。

想问下大家按照gpt现在这种发展速度，个人还有必要花精力在clean code上吗？可能以后code的精简gpt或者某个ide插件就能做了，我们focus在logic就行了。

匿名用户 发表于 2023-03-17 15:31:22
想问下大家按照gpt现在这种发展速度，个人还有必要花精力在clean code上吗？可能以后code的精简gpt或者某个ide插件就能做了，我们focus在logic就行了。

按照这发展速度还写啥code？直接写prompt，然后做个prompt-based code generation CICD backend，以后PM自己写logic，码农全是fat，全裁掉，完美🐶

如果说不过他，那就照做吧。要productivity就加班吧，慢慢熟练了以后就不用加班了

不如一开始就照他的意思写