review 代码只是走过场怎么办

个人认为 review 不光是检验代码质量，因为 review 了不代表就提升了代码质量。
更多的是互相交流对齐，共同进步的工程，利远远大于弊。

当你只有十行代码的时候，review 的评论可能有几十条。
当你有五百行代码的时候，review 瞬间就被通过了

PM 同意你晚几天上线没？晚一周少一百万实名用户的教训还少吗

@123444a 祝你们公司永远没有单元测试和 CR 吧

没有 code review 绝对不行
但是，code review 搞不好也会成为一种阻碍生产力的工具

要平衡

@123444a 我司的代码因为没有 review 和质量保证，导致一个更新晚了 2 年半才上线。

我觉得有 CR 这个流程是好的，但是还是看人，如果碰到不怎么 care 的人不去看那怎样的流程都没办法。

既然同事拒绝 review 代码了，那你们各自开个自己的代码目录项目，相互 rpc 通信调用，自己玩自己的吧，别用分支合并了，这样出问题背锅好解决，谁由于 bug 多影响产品也好定位。

1. 合理排期, 安排好 Review 的时间花费.

2. 单次 PR, Commit 次数不宜太多.

3. 看不懂的代码建议 评论 或者 拒绝掉 PR.

当然是互相伤害啊 “认真” review 同事的代码

review 可能会避免一些比较低级的问题，或者一些隐藏的问题
当然把代码拿出来讲，一些逻辑的处理方式互相交流也是好的

很多写程序的人其实是在用厨师，外卖员，裁缝还有卡车司机的思维在干着程序开发的工作，相比于编程，后面的这些职位更加适合他们，这是由于当前国内人才培养机制不完善，而企业又急需大量开发人员的问题导致的，当所有人都做对的事情，而你做错的时候，大家会纠正你，通化你，而当所有人都做错而只有你是内行，用专业手法做事情的时候，其他人照样会通化你，努力让你和他们一样不规范的做事。对于这种情况，网上的一句话很能说明问题，“要么忍，要么滚”，能忍下来，打一份工，赚钱养家，这无可厚非，如果忍不了，想要充分发挥自己更大的优势，做一点将来自己年老时可以拿出来怀念与炫耀的事情，那么就去找更好的同事，更好的团队吧，因为并不是所有的努力得到的回报率都是相同的，不同的环境，不同的团队，会相应增加，或者降低回报率，想要有所作为，与其生闷气，不如另谋高就来的更爽快。

@renmu #2 我们是不是在一个公司 [狗头][狗头]

@exploreXin cannot agree more

测试岗位起来走两步？

到了 v2ex，发现所有人都觉得同事是猪，但可能你同事也在上这个论坛呢。。

国内能认认真真 review 代码的公司屈指可数吧？

基本上都是以业务结果为导向，谁关心你代码质量，只要能跑不出故障就行了，你说 review 是图啥？自己为自己代码负责，甭想通过 review 解决潜在的 bug

而且很多代码都是涉及到具体的业务逻辑，你不了解这块功能也不好下结论，所以 review 啥呢？代码规范吗？

最后，时间上也不允许，大家都忙的很

先上 sonar 之类的静态检查工具，粗滤一遍

另外 cr 需要提前提交代码，不能快到 dealline 了提交一个巨大的 commit，这是不负责任的。

CR 很考验 reviewer 的能力的，学了几天 code 的人怕是 re 不动啊。