代码评审带来的好处不言自明, 但企业业务快速发展的诉求与代码评审推动落地两者之间, 往往存在矛盾。到底选择重评审，还是轻评审？今天我们继续跟着云效代码团队同学一起认识下轻重评审，探讨下企业如何选择适合现在发展阶段的评审模式。
我们可以基于评审过程的严格程度，把评审分为轻/重两类，可以根据自身业务情况选择最合适的评审方式。
|
轻评审 |
重评审 |
卡点 |
合并时走评审，但不设强制卡点 |
合并必须走评审流程，设强制卡点 |
评审严格度 |
评审者自行决定 |
严格度高，评审人必须审阅且通过 |
评审追求 |
迭代速度优先 |
安全质量优先 |
适用团队 |
敏捷研发、质量风险要求不高的团队 |
迭代速度稳定、质量风险要求高的团队 |
1. 轻量级评审
轻评审即轻量级评审，适合将迭代速度放在第一优先级的产研团队，对代码质量和上线后的风险方面有一定包容度。
在研发资源极度紧张，业务需求井喷的场景下，质量和速度是鱼和熊掌不可兼得的事，很多初创企业的管理者或者是技术Leader都选择接受一定的技术债务。在研发流程上，不要求一定满足严格的评审合入准则， 在这种情况下，轻评审是不错的选择。
2. 重量级评审
重量级评审与轻量级评审采取不同的策略，有严格的卡点规则，通常见于以下场景：
∙ 业务类：对于代码质量要求较高的业务模块
∙ 服务类：基础类应用、中台类应用、通用性工具
∙ 开源类：开源贡献场景通常对于代码质量的要求较高
3. 灵活的卡点支持
不同的企业对于代码评审的卡点支持上，通常主要关注通用性、扩展性和灵活性三个维度。
1） 通用性
通用卡点主要包括：
∙ 支持代码冲突检测结果作为合并卡点 。
∙ 待解决评论作为合并卡点 。
∙ 评审人评审是否通过作为合并卡点 。
2） 扩展性
扩展性主要体现在，根据自身业务诉求，在基础卡点类型基础之上，支持扩展平台内置或者三方接入的自定义卡点：
∙ 代码风格：支持 code-style 检测结果作为合并卡点。
∙ 代码规范：支持代码规范类检测结果作为合并卡点。
∙ 代码测试：支持单元测试、集成测试、可交付测试等测试结果作为合并卡点。
∙ 安全合规：支持依赖包漏洞检测、代码漏洞检测、代码扫描检测、开源合规检测等检测结果作为合并卡点。
∙ 其他自定义卡点类型。
3） 灵活性
通常在一些特殊的场景下，尽管设置了代码评审的相关卡点，你可能仍旧希望在特定规则下，可以灵活的控制卡点的生效逻辑，包括：
可灵活选择观测项结果是否作为卡点，例如只希望对代码风格进行检查和结果查看，但
是不作为真正卡点阻碍代码的合并过程。
在紧急发布情况下，本地已经验证通过，希望临时将某些卡点检查自动跳过，从而尽快进行合并从而修复线上缺陷。
基于以上通用性、扩展性、灵活性的卡点考虑，代码评审应该灵活支持企业内不同的团队对于轻量级评审和重量级评审的不同诉求。
云效 Codeup 的新版代码评审通过对于合并卡点的理解和抽象，支持常见基础卡点以及自定义卡点(灰度中)，进而提供该方法论的支撑落地方案：
云效 Codeup 新版代码评审支持常见基础卡点以及自定义卡点(逐步开放中)
