随着业务规模扩大、团队组成变复杂，如何降低项目实施风险，降低软件复杂度变得尤为关键。 我从 Martin Flower、Joel Spolsky（软件随想录 作者） 等巨匠智慧中寻找解决复杂工程之道，其中 Code Review 是行之有效手段。 我认同 Code Review 价值也是忠实执行者。

加入蚂蚁以后，我在所接触项目中都大力推广 Code Review。 感谢团队信任和支持，目前 CR 协作进展顺利， 项目 CR 从最早不主动，到现在形成基于模块 Owner 制度 CR 和 Peer Review。 我也曾经在 3 个月内处理完成 700 多个 Pull Request，并在 PR 讨论中中都留下一些有价值讨论。 这里我将自己对 Code Review 一些理解记录下来。

这一篇先讲讲进入 Code Review 之前需要做准备工作。

评估团队成熟度

不管是在一个遗留系统上推广 Code Review，还是在一个新团队推广 Code Review， 起手式不是立马挽起袖子猛干，而是应当观察一下当前所处情况是否允许自己推动这个「艰巨」任务。 最需要观察的是团队成熟度。

我将团队成熟度粗略分为草台班子、成长型团队、成熟团队。 具体衡量指标可以有成员技术储备、团队成员信任度、团队负责人对工程管控力度。 相信集团内大部分团队处于成长型、成熟型团队。 但如果考虑到生态同学一起协作，或者临时因为紧急项目凑在一起，就比较容易成为「草台班子」。

如果还停留在草台班子，那就得先在团队内形成一定共识： 包括技术共识和合作模式的共识。 技术共识需要包括：技术栈共识、好代码定义、研发流程共识等。 合作模式共识需要包括：冲突解决机制、职责范围边界、决策机制等。 如果基本共识还没有形成就仓促进入 Code Review，那就容易将一件好事变成工程师战争。

并不是所有团队、项目都适合无差别引入 Code Review。这么几种情况建议暂缓 Code Review 推广：

• 老板和同事都不支持甚至反对
• 业务重要性低，或者团队都是特立独行高手
• 创新业务需要快速上线，这时候适合将这类任务分发给配合度高老团队，或者给高手单兵作战

当条件不满足时也不用气馁。先成为一个布道师吧，探索一下团队中有没有相似想法的人，了解一下他们担心点和诉求点。 相信只要条件允许，没有人会拒绝提高工程质量。

构建「好代码」共识

Code Review 核心产出物是代码，如何界定代码是好是坏就至关重要。 根据 Bjarne（「C++ Programming Language」作者）、Grady Booch（「面向对象分析与设计」作者）等人定义， 总结下来好代码有这么基本特征（via「Clean Code」）：

• 正确
• 可测试
• 不重复
• 少且简单
• 可读

深思一下这些基本特征背后道理：代码是人类和机器沟通工具，好代码也要利于人类阅读和再次书写。 人比机器更犯错，机器算力在成倍增长，因此简单易维护重要度逐步增高。 这些朴素道理也正是语言从低级语言进化到高级语言驱动力， 也是近几年高级语言语言特性主打点（类型系统、格式系统、面向人类同步思想异步设计）。

但上面这几条原则太底层了，无法成为实践标准。 因此行业基于这些公理衍生了不少实践定理，我将其分为工程规约和设计范式两类。

工程规约包含语言风格规约和应用工程规约。 语言风格规约比较容易理解，开源世界提供了很多选择。硅谷大厂 Google / Facebook / Uber 等都有不少规约提供。 国内还有极具价值的「阿里巴巴 Java 开发手册」，我称之为 50331 ;) （PS：「阿里巴巴 Java 开发手册」不仅有语言风格规约、也有应用工程规约和一部分设计规约）。 这里罗列了一些常见面向语言的 Style Guide。

• Google Style Guides | styleguide
  • 包含 C++ / Object-C / Java / Python / R / Shell / HTML CSS / JavaScript / AngularJS / Common Lisp / Vimscript
• alibaba/p3c: Alibaba Java Coding Guidelines pmd implements and IDE plugin
  • Java
• airbnb/javascript: JavaScript Style Guide
  • JavaScript
• uber-go/guide: The Uber Go Style Guide.
  • Go

应用工程规约关注点则更为落地：包括依赖管理、配置管理、应用层次结构、对外服务暴露约束，数据建模，文档注释，测试管理， 甚至包含中间件使用规约。 这些规约逐步从「如何表达代码」延展到到「如何管理工程」。 这块发挥空间比较大，中大规模团队会有应用框架组这样团队。 基于应用框架对使用方式方法约束。针对具体业务使用也会给出针对性建议。 这些定理总结出来往往以轻量 Best Practice 和重量级应用框架对外输出。

这里举两个例子说明一下应用工程规约应该讲清楚哪些问题。 第一个例子 alibaba/COLA 这个项目来说，它约束了整体工程结构，并且明确的通过 Archetype 帮助（约束）用户行为。 第二个例子是 RoR / Django 这类 RoR 框架，他们使用约定大于配置方式，基于 ActiveRecord 这种模式约束了用户如何使用框架， 从 Model、Controller 到 Router，对立面则是 Spring MVC...