review 代码只是走过场怎么办

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

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

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

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

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

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

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

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

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

一起加入 linux kernel community