这说明你们的工作量极度不饱和，不然哪有空折腾这个。 我司对我们的要求是：按时完成项目并按计划交付项目，代码的可靠性、可维护性和安全性被放在次要地位。

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

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

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

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

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

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

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

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

给钱了吗？拿钱了就改啊