软件开发还没测试就代码评审？是评审还是批斗

你有没有遇到过这种情况？

代码刚写完，功能还没跑通，测试一个都没过，leader就拉着大家开始代码评审了。然后呢？一群人围着你的代码指指点点，这个变量命名不规范，那个函数太长了，这里应该用策略模式...

简直就是公开处刑啊，今天就发生在我的身上，亲身经历了这波批斗，

别人写的shi山，而且还没离职，为什么要让我来改，评审不在代码，重在批斗，测试刚反馈过来问题，您的代码评审会已经开始了，老板你真棒。

基于别人的风格写的代码，因为加了个变量，你就展开说是我的问题？请问你们评审质量在哪里呢？怎么让这shi山堆上来的

代码评审怎么就变味了

其实代码评审本来是个好东西。

但是！很多团队把它搞成了技术批斗大会。你想想，代码都还没跑起来，功能对不对都不知道，就开始扣细节，这不是本末倒置吗？

我见过最离谱的，有个团队要求每天下班前必须代码评审。不管你代码写到哪了，反正时间到了就得评审。结果呢？大家为了应付评审，写一堆半成品代码，评审的时候也是鸡同鸭讲。

先跑通再优化不香吗

做了这么多年开发，我觉得正确的顺序应该是：

先让代码跑起来 基本测试通过 再来谈优化

很多技术leader喜欢在代码评审时秀技术，什么设计模式、架构思想满天飞。但问题是，你的代码能解决实际问题吗？能按时交付吗？

之前开发时，从来都是功能验证通过后才组织评审。这时候大家的关注点才真正在代码质量上，而不是在猜测"这段代码可能是想实现什么功能"。

真正有价值的代码评审，应该关注这些：

业务逻辑的正确性

代码是否真正解决了业务问题？是否做了回归测试？是否到了评审时机？

潜在的bug和风险

比如并发问题、边界条件、异常处理等。这些才是评审的重点。

性能瓶颈

特别是涉及数据库操作、循环嵌套这些地方。

至于什么变量命名、代码风格，说实话，有代码规范和工具自动检查就够了。非要在评审会上纠结这个大写还是小写，真的很无聊。