被 Code Review 折磨疯的组员

看得懂就不错了，语法糖的东西。。。

没有 eslint 规则之类的吗?定好规则,让机器 review 呗

@Romic 好吧， 忘记了加班没加班费的情况了

兄弟：世界不是这样运行的，人家也许是面子上过得去就随口提了下，并不是真的要你如何改！
没有业务错误就可以，写代码记住，能运行就别动
世界运行方式很复杂，并不需要认真对待每一个

兄弟，主动找他要个裁员大礼包走吧，你们不适合

0 总之不爽辞
1 Code Review 的人是谁, 为什么有权让你改?
1.1 组长? Leader? 不爽辞
1.2 组员? 完全可以拒绝或向上申请复议或者全组公开讨论


2 Code Review 应该在测试前之前就做完改完


3 整体重写的情况非常非常少, 是否是开发前的方案设计讨论就不充分


4 针对编码风格, 应该全组讨论制定统一的规范; 如果自己维护的业务在全周期由自己负责, 那你可以随便操, 反正也是鹅心下一个接盘侠; 如果是多人共同维护或者定期轮换, 你也不想维护被别人私自随意操烂的代码吧

@S1ahs3r #5 笑死，我遇见过

之前我的上司不懂 js ，review 我的 pr 叫我把字符串的单引号改双引号，我没反驳，按照他说的改了

ai 写代码，
ai review ，
ai 根据 review 修复
上线后出 bug ，全滚蛋了

这说明你们的工作量极度不饱和，不然哪有空折腾这个。

我司对我们的要求是：按时完成项目并按计划交付项目，代码的可靠性、可维护性和安全性被放在次要地位。

很简答，他给你 review 代码，不意味着对方的代码是正确答案，你再对他的代码进行 review 就行，更好的写法花点时间肯定能找到更好的，每次对方给你 review ，你就给你就给他 review 更好的写法，然后写个小文章，为什么要这么做，这样你自己能力也能提升，也能让对方知道自己 review 代码的局限性

最恶心的是严于他人，宽以自己的。 自己写的代码各种原因都能过，换成别人的代码化身为架构师的杂总

@MrRongts #12 他是什么角色，是他可以 review 你们，你不能 review 他？

@SignUpWithSolana 我觉得他很懂，双引号是对的

这种活最轻松啊，改就改呗，能让改说明项目也不是很赶啊，不然就让老大决定功能都 ok 了，再改来改去又延期风险。反正给时间不额外加班改这个都能接受

手动实现还是用语法糖这种 review 的时候都要改，这还是太闲了，赶着上线的话锅要全部他一个人背？
正常的 code review 应该是侧重性能问题工程合理性啥的吧，比如 for 循环取数改为批量取，已有的逻辑不要重复实现，逻辑都写在 controller 层，漏掉一些异常处理这些
不然你就让他每种语言出个 lint ，别你写完了他想到哪你们改到哪

我第一份工作跑路很大一部分原因就是一个比我早两年毕业的睿智 cr 老恶心我

code review 有没有给出合理的理由？如果有，建议你心平气和的想想对方的理由是否合理。如果没有，就是纯粹的服从性测试，不敢辞就忍

给钱了吗？拿钱了就改啊

比较优秀的做法是：每一次 pr 都有 review ，而不是全都写完了，QA 都测完了才 review ，然后重写，这样会导致 QA 也要重新测试。