我以前也是被 code review 折腾了一会儿，总要按照对方的方式来改。有时候就是口味不同而已。 并没有写法的高低。 后来，我们在写代码之前会大致把开发方案先写出来，一起过一下，再开始开始，这样的话，后面的 code review 只会看一眼代码的风格，代码的方向可以不用再有纠结的地方了。

光看这个帖子：『 Code Review 经常性把别人的写的都推翻』，也很有可能是 reviewer 觉得自己带了一堆菜*还感觉无论如何都带不动那种 但看了你上个帖子里的例子，怎么说呢。 我觉得要是有**更**合理的理由（比如要支持上古的 IE ）其实 reviewer 的写法的确有道理，只是讨论可读性的话在这个例子上过于牵强，除非其他人都是上古程序员。。。

珍惜认真 Review 你代码的人吧。大多数人水平真的很一般可能自己还认识不到。 如果 Leader 的技术追求，技术审美，和技术水平都比你高，你就多学习学习。

@MrRongts unwrap 不 panic 了么...

感觉有的人好像被 pua 习惯了 这种 leader 可不一定是有啥技术追求 单纯就是想搞一言堂 把组员当 AI 用 这种真就别忍着 你忍不住的 早点摆烂等着大礼包就得了

风格统一是必要的，风格由谁定，当然是你的领导。

你的 leader 也很无奈，不 review ，其他组的 leader 看到了不符合规范的代码，不显得自己也很菜么。review 吧，是人都讨厌别人找问题，重复工作，下面的人有意见，很难的。 所以我都是带着其他组员，开大会 review ，把火力分散出去，大家都觉得你写的有问题，那你大概率有问题了。

明显是流程的问题，code review 应该小步快跑，每个 commit 的内容少一些，反馈快一些，这样就不会改了一大堆全部被推翻。review 过了之后才会接受这个 merge ，才能进入功能测试流程呀，这样就不会出现产品上线等你这个 review 的修复了。

我在阿里进行 code review 的时候，committer 面对我提的意见会说：你提的建议我都理解，但是这个需求是 XX 老板点名今天晚上要上的，现在马上管控了，如果上不了这个锅你来背，之后我都是秒点通过。

这说明你们在 code review 之前还应该再有一轮 design review 呀