可以说，推崇Code Review几乎是一种政治正确，尤其在一些外国大公司或国内硬核技术领域的创业公司。
本人也待过几家大公司，很多硬性要求Code Review，但最终都流于形式，审核人直接点通过，谁有那闲工夫给你认真看呢？况且很多东西就是个人主观的看法，容易扯皮。
还有公司定期组织人，一起Code Review，但也就是个仪式，那么短的时间，能看出啥呢？都是些不痛不痒的代码品位问题，比如抠“for循环里，数据总量获取步骤”应该放循环外面这些不痛不痒的小改进。
对于代码格式问题，直接统一一个代码规范即可，借助IDE或sonarqube之类的代码审查工具，不符合条件的代码给出提示或不让提交即可，压根没必要人工去审核，浪费时间。
况且Code Review属于管中窥豹，只能看出局部的小问题，对于设计模型，架构方面的问题，很难看出来。等出了问题再去看，也为时已晚。
与其关注代码质量，不如关心下流程和结构设计。
我曾组织人在项目开始集中宣讲项目模块的流程设计，包括代码怎么存，怎么取，怎么设计缓存，怎么解决的效率问题，有没有并发或数据不一致问题。还有就是数据或状态流转问题，怎么去承接这些变化，怎么利用队列，规则引擎，内存缓存来优化数据处理效率。有没有参考业界一些通用做法。项目完了可以自愿决定是否再讲讲遇到的坑，解决方案或业界同类的方案。
宣传尽量避免讲具体代码，参与人也不只是对应技术栈的人，还包括了其他端，或测试，产品，UI等。宣讲的内容，可以直接作为将来晋升答辩的内容。
这么多年来，我个人深有体会，造成项目混乱的问题，根本就不是代码问题，而是流程或架构设计问题，在开发迭代的过程中，如果底层业务模型或架构设计无法满足产品需求，导致推倒重来或各种补丁。
个人的提升，主要是方案或架构设计方面，跟代码也没有太多关系。