代码审查者应该关注哪些方面？
代码审查时应该关注以下方面：
- 设计：设计是否合理？
- 功能：是否满足prd需求？是否满足用户流程交互合理性？
- 复杂度：代码能更简单吗？将来其他开发人员能轻松理解并使用此代码吗？
- 测试：代码是否具有正确且设计良好的单元测试？
- 命名：开发人员是否为变量、类、方法、包等选择了明确的名称？
- 注释：注释是否清晰有用？
- 风格：代码是否遵守了代码规范？
- 文档：开发人员是否同时更新了相关文档？
设计
审查中最重要的是 CL 的整体设计。CL 中各种代码的交互是否有意义？现在是添加此功能的好时机吗？
单一职责原则 (Single Responsibility Principle)
- 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分；
- 类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分；
- 私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性；
- 比较难给类起一个合适名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名，这就说明类的职责定义得可能不够清晰；
- 类中大量的方法都是集中操作类中的某几个属性，那就可以考虑将这几个属性和对应的方法拆分出来。
违背SRP原则的案例
1.CreditSchemaAbilityImpl中函数、依赖过多，充斥着类转换逻辑、访问facade逻辑、工厂逻辑、私有方法过多、大量私有方法最终只是得到一个字段值等。
2.User类中大量方法操作的都是UserAddress成员变量对象，而这些方法散落在User类而不是委托UserAddress类。
开闭原则 (Open-Closed Principle)
添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。关于定义，我们有两点要注意。第一点是，开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。第二点是，同样的代码改动，在粗代码粒度下，可能被认定为“修改”；在细代码粒度下，可能又被认定为“扩展”。
我们要时刻具备扩展意识、抽象意识、封装意识。在写代码的时候，我们要多花点时间思考一下，这段代码未来可能有哪些需求变更，如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，在不改动代码整体结构、做到最小代码改动的情况下，将新的代码灵活地插入到扩展点上。
最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态）。
违背OCP原则的案例
public class Alert {
private AlertRule rule;
private Notification notification;
public Alert(AlertRule rule, Notification notification) {
this.rule = rule;
this.notification = notification;
}
public void check(String api, long requestCount, long errorCount, long durationOfSeconds) {
long tps = requestCount / durationOfSeconds;
if (tps > rule.getMatchedRule(api).getMaxTps()) {
notification.notify(NotificationEmergencyLevel.URGENCY, "...");
}
if (errorCount > rule.getMatchedRule(api).getMaxErrorCount()) {
notification.notify(NotificationEmergencyLevel.SEVERE, "...");
}
}
}
上面这段代码非常简单，业务逻辑主要集中在 check() 函数中。当接口的 TPS 超过某个预先设置的最大值时，以及当接口请求出错数大于某个最大允许值时，就会触发告警，通知接口的相关负责人或者团队。现在，如果我们需要添加一个功能，当每秒钟接口超时请求个数，超过某个预先设置的最大阈值时，我们也要触发告警发送通知。这个时候，我们该如何改动代码呢？主要的改动有两处：第一处是修改 check() 函数的入参，添加一个新的统计数据 timeoutCount，表示超时接口请求数；第二处是在 check() 函数中添加新的告警逻辑。具体的代码改动如下所示：
public class Alert {
// ...省略AlertRule/Notification属性和构造函数...
// 改动一：添加参数timeoutCount
public void check(String api, long requestCount, long errorCount, long timeoutCount, long durationOfSeconds) {
long tps = requestCount / durationOfSeconds;
if (tps > rule.getMatchedRule(api).getMaxTps()) {
notification.notify(NotificationEmergencyLevel.URGENCY, "...");
}
if (errorCount > rule.getMatchedRule(api).getMaxErrorCount()) {
notification.notify(NotificationEmergencyLevel.SEVERE, "...");
}
// 改动二：添加接口超时处理逻辑
long timeoutTps = timeoutCount / durationOfSeconds;
if (timeoutTps > rule.getMatchedRule(api).getMaxTimeoutTps()) {
notification.notify(NotificationEmergencyLevel.URGENCY, "...");
}
}
}
这样的代码修改实际上存在挺多问题的。一方面，我们对接口进行了修改，这就意味着调用这个接口的代码都要做相应的修改。另一方面，修改了 check() 函数，相应的单元测试都需要修改（关于单元测试的内容我们在重构那部分会详细介绍）。
里氏替换原则 (Liskov Substitution Principle)
子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。
判断子类的设计实现是否违背里式替换原则，一个小窍门，那就是拿父类的单元测试去验证子类的代码。如果某些单元测试运行失败，就有可能说明，子类的设计实现没有完全地遵守父类的约定，子类有可能违背了里式替换原则。
违背LSP原则的案例
子类违背父类声明要实现的功能父类中提供的 sortOrdersByAmount() 订单排序函数，是按照金额从小到大来给订单排序的，而子类重写这个 sortOrdersByAmount() 订单排序函数之后，是按照创建日期来给订单排序的。那子类的设计就违背里式替换原则。
子类违背父类对输入、输出、异常的约定在父类中，某个函数约定：运行出错的时候返回 null；获取数据为空的时候返回空集合（empty collection）。而子类重载函数之后，实现变了，运行出错返回异常（exception），获取不到数据返回 null。那子类的设计就违背里式替换原则。在父类中，某个函数约定，输入数据可以是任意整数，但子类实现的时候，只允许输入数据是正整数，负数就抛出，也就是说，子类对输入的数据的校验比父类更加严格，那子类的设计就违背了里式替换原则。在父类中，某个函数约定，只会抛出 ArgumentNullException 异常，那子类的设计实现中只允许抛出 ArgumentNullException 异常，任何其他异常的抛出，都会导致子类违背里式替换原则。
子类违背父类注释中所罗列的任何特殊说明父类中定义的 withdraw() 提现函数的注释是这么写的：“用户的提现金额不得超过账户余额……”，而子类重写 withdraw() 函数之后，针对 VIP 账号实现了透支提现的功能，也就是提现金额可以大于账户余额，那这个子类的设计也是不符合里式替换原则的。
依赖倒转原则 (Dependence Inversion Principle)
- 高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）。
违背DIP原则的案例
1.在sop流程中提供通用功能，拓展点却依赖了具体实现环节中的类，关心了具体实现。
2.在某个类中依赖了某个接口具体实现类，而不是依赖接口。
3.没有按照DI方式分层，单测困难。
4.没有通过spring ioc容器控制反转，直接在类中new成员变量，单测困难 ， 依赖细节。
接口隔离原则 (Interface Segregation Principle)
客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。
违背ISP原则的案例
1.为了程序分层方便api将对数据库的逻辑DELETE方法也暴露对外了，造成风险。
2.由于接口设计不佳，授信领域间接被强迫依赖了支用领域接口。
3.一个接口方法功能太多，只能兼容一些入参白跑了很多多余的逻辑。
迪米特法则（Law Of Demeter）
每个模块（unit）只应该了解那些与它关系密切的模块（units: only units “closely” related to the current unit）的有限知识（knowledge）。或者说，每个模块只和自己的朋友“说话”（talk），不和陌生人“说话”（talk）。
不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”）。
违背LOD原则的案例
1.文件上传接口FileUploadInterface依赖了OSS的Bucket对象，而不是定义抽象的文件上传参数，文件上传不一定要用OSS实现的。
2.还款实体为了得到某个字段，依赖了征信实体，只因为征信实体里面有这个字段，获取方便，但是征信不属于还款领域概念。
功能
背景了解
Code Reviewer 要知道改动的背景，本次改动代码是为了做什么？不能做什么？会影响什么？
逻辑分析
Code Reviewer 根据需求背景，对代码逻辑进行分析，是否满足需求，是否有业务逻辑漏洞。
边界检查
Code Reviewer 检查改动影响的功能模块，是否有边界问题，如果是refactor change，应当检查兼容性，如果是feature change，需要检查领域边界是否合理。
异常监控
Code Reviewer 检查日志处理、异常处理、监控埋点方式等代码，是否存在缺陷、丢失。
非业务功能性检查
Code Reviewer 检查多线程、并发、代码安全、性能等角度，是否存在漏洞，是否可以优化。
复杂度
圈复杂度
Code Reviewer 检查代码圈复杂度情况（if while分支过多、方法分支太多），圈复杂度在1-10为合理范围。
改进方法
- 简化、合并条件表达式
- 将条件判定提炼出独立函数
- 将大函数拆成小函数
- 以明确函数取代参数
- 替换算法、策略模式
方法长度
代码长短可以直接说明它复不复杂、阅读成本高不高，长度度量往往是复杂度分析里最简单直接的手段。此处，有效代码长度 = 代码行 - 空白行 - 注释行。当前，集团95%的方法的有效代码行数在42以内。
方法参数长度
方法参数过多会降低容错性、模糊表达意图，参数个数应当在3个以内，可以通过静态创建、参数合并为Model等方式降低长度。
最高结构控制层数
花括号 { } 的最大嵌套层数。深度嵌套的代码总是像俄罗斯套娃一样晦涩难懂，可读性和可维护性大打折扣。当前，集团95%的方法的最大嵌套层数在3以内。
设计复杂度
是否有over设计的情况，简单的两个分支，拓展性低的case，做成了策略模式之类的。
测试
case覆盖率
Code Reviewer 检查单测case覆盖情况，是否覆盖了主要业务流程，严格来说每个逻辑分支都需要覆盖。
可测性
Code Reviewer 检查代码中是否有环境、外部、静态类等依赖，如有，会影响单测隔离性，单测应该可以通过打桩隔绝任何依赖。
规范
单测代码也需要规范，清晰易读，重复性低为准。
命名、注释、风格
代码规范
文档
文档更新
Code Reviewer 提醒 developer 在二分库、应用等升级之后更新文档。
如何撰写 Code Review 评论
总结
- 保持友善。
- 解释你的推理。
- 在给出明确的指示与只指出问题并让开发人员自己决定间做好平衡。
- 鼓励开发人员简化代码或添加代码注释，而不仅仅是向你解释复杂性。
糟糕的示例：“为什么这里你使用了线程，显然并发并没有带来什么好处？”
好的示例：“这里的并发模型增加了系统的复杂性，但没有任何实际的性能优势，因为没有性能优势，最好是将这些代码作为单线程处理而不是使用多线程。”
引用
- <设计模式之美> 王争
Google