review 代码只是走过场怎么办

[Noobs]

虽然用只有自己的代码不经过 review 也能上线才能独挡一面来安慰自己，但是仍然对同事拒绝 review 代码感到不可理解

[qwefdrt]

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

[renmu]

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

[123444a]

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

[lights]

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

[ericgui]

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

要平衡

[msg7086]

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

[daozhihun]

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

[zjsxwc]

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

[TTC]

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

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

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

[vindurriel]

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

[sumarker]

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

[exploreXin]

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

[sadfQED2]

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

[ocean1477]

@exploreXin cannot agree more

[7654]

测试岗位起来走两步？

[hbolive]

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

[wangbenjun5]

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

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

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

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

[optional]

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

[optional]

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

[wednesdayco]

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

[Dongxilemo]

这个时候就只有规范代码了…

[Elephant696]

团队以前也研究过 review 代码，主要有几个问题比较难解决。

一、新业务开发中，review 代码就意味着你首先要熟悉这部分的业务，包括产品，接口等，产品还好说，接口就要看后端的文档是否完善了，指不定开发的时候有什么特殊的字段啥的，如果你不知道，那就没法理解前端处理的逻辑。但这无疑是增加了巨大的工作时间和精力，在业务为导向的我们目前根本没有时间去做这件事。

二、bugfix 中，review 代码会相对花费的精力和时间要少一点，但可能涉及到其他的一些库的 bug，或者用了什么组件的 bug，这你就要去查找文档之类的，也是很麻烦。

所以目前，review 主要是看代码风格和代码质量，至于业务逻辑实在没精力去搞

[chenliangngng]

review 是有必要的，尤其是不稳定的团队和刚组建的团队，磨刀性质

[hantsy]

1, Code Review 是相互交流的过程。提高代码质量，和交换一些实现方法。
2, 代码逻辑正确与否，主要是用测试代码来实现，分支 PR 跑 CI 服务器。

[nianyu]

你去任何公司 review 代码其实都是走过场。这个道理还想不明白

[Noobs]

六字诀早就烂熟于心了，把自己的职场困惑发出来讨论一下，免得钻了牛角尖还不自知吧。
code review 显而易见的好处就是加强团队沟通和代码
质量保证，实施起来的话问题其实就是谁也不想添加自己的工作量吧，各人自扫门前雪。可能比较好的解决方案是根据代码改动影响范围酌情 review 。要是重要改动都没人做靠谱的 review，那就没天理了，早点闪人吧，常在河边走哪有不湿鞋(发现自己很害怕出事故背锅啊…)。
说靠责任心的，感觉和期望当官的自觉清廉一样，只能当官的说给自己听。说工作忙没时间的，我理解也应该是少数时间忙到没时间 review 代码吧。
用工具做检测的话，其实算另外一种保证代码质量的手段吧，不知道 sonar 可不可以搞 c++ 跨多个文件的检测和到底有多强，用过 clangtidy，cppcheck 之类的，感觉有点弱

[123444a]

一起加入 linux kernel community