CodeReview的挑战

保证CodeReview质量的前提条件

有良性的社交压力

保证CodeReview质量的先决条件在于建立一个良性、有效的社交压力机制。这种机制始于招聘过程，我们需要吸引那些拥有基础专业素养的开发者，其中包括能够承受并积极响应CodeReview中社交压力的能力。

设想一下，当你紧张地编写代码，而交付时间又步步逼近时，面对组织对单元测试的严格要求，你可能会考虑降低标准，甚至为了应付工具的覆盖率要求而编写一些不那么有用但能提高覆盖率的测试。然而，一想到你的代码即将接受同事们的严格审查，那种压力便会促使你避免选择那些短期收益高但长期损失大的“投机”行为。

CodeReview是对前面所有工作的检查

下面是我总结的CodeReview的关注点：

基础功能方面

修改范围：我在CR时第一关注点是修改范围与需求是否一致，如果修改范围扩大，会造成变更不可控，是极为危险的。

安全性：是否有严格的准入校验，检查是否有可能导致安全问题的地方，如SQL注入、跨站脚本（XSS）问题等。对于敏感数据，要确保其在使用、传输和存储过程中的安全性。

功能实现：代码是否满足功能需求或修复了相应的Bug，代码实现的逻辑是否正确？这个会通过在方案评审时就做好准备。设计方案评审需要3人以上有CR权限同学参加，最后CR人至少是这三人中的两个。

自我检查机制：比如与第三方交互前后要打日志，是否需要配套相关的数据一致性措施。当然，这些在设计阶段一般会定好。

错误和异常处理：检查是否有错误处理和异常处理机制，以防代码在遇到错误时崩溃。

可靠性方面

性能优化： 检查代码是否有可能影响性能的地方，如是否有不必要的循环，是否使用了正确的数据结构、算法时间复杂度和空间复杂度是否达标。

可维护性和可扩展性： 针对代码的结构和设计进行审查，代码是否易懂，接口设计是否良好，逻辑是否清晰，是否遵循遵循开放/封闭等设计原则，是否利于后续的扩展和维护。

可测试性：检查代码是否容易进行单元测试，是否有足够的测试覆盖率。这个一般会通过CI/CD来保证，一般会有一个整体性的要求，比如要达到85%的行级单测覆盖率、80%的分支覆盖率、100%的单测成功率。但需要人工Review来保证这些测试案例是真正有效的案例。

可以发现这些关注点，需要在设计阶段就定义好，CodeReview是做兜底的。CodeReview发现的问题，问题可能不是在编码阶段才产生，需要去仔细辨别问题发生的环节，做深入剖析。

CodeReview中最突出的问题

真正的问题没有发现，纠结的问题与开发者无法达成共识

有的同学做CodeReview的时候，依赖的是差异对比工具，往往只看到改了什么，但没有对工程深刻的理解，也没有实际把代码放到IDE中追踪修改方法被调用的地方涉及到几处，可能修改范围被扩大了，没有发现。发现的只是一些可维护性方面的问题，通常是一些代码坏味道，常见的包括：

重复的代码、过长函数、过大类、过长参数列、发散式变化、霰弹式修改、依恋情结、数据泥团、基本型别偏执、冗赘类、夸夸其谈未来性、令人迷惑的暂时值域、过度耦合的消息链、狎昵关系、异曲同工的类、内幕交易。

这些问题都非常重要，但带着这些问题上线不一定会引起真正的线上问题。但是修改范围扩大造成的影响可能会产生预想不到的问题。也有很重要的一点：代码坏味道的问题，往往仁者见仁，就像zookeeper建议部署单数个节点一样，两个人不容易协商出共识。谁妥协得多了，都会造成影响力方面的损失。

所以这对CR同学的技术功底提出了很大的挑战，CR同学需要是把事情想明白的人。比如，提出下面的CR问题。

未使用最佳实践：例如，未使用Java 8及以上版本的特性（如Lambda表达式、Stream API等），或者未使用第三方库来简化代码。

这就面临着需要和开发者解释清楚：

未使用Java 8及以上版本的特性（如Lambda表达式、Stream API等）可能会造成以下问题：

1. 代码可读性降低：Java 8引入的Lambda表达式和Stream API等特性可以极大地简化代码，提高代码的可读性。如果未使用这些特性，可能会导致代码冗长、复杂，从而降低可读性。

2. 代码效率降低：Stream API等特性可以更加高效地处理集合数据，例如过滤、映射、归约等操作。如果未使用这些特性，可能会导致代码效率降低，尤其是在处理大量数据时。

3. 难以维护：随着Java版本的更新，新的特性和工具不断出现，使用这些新特性可以更方便地维护和更新代码。如果未使用Java 8及以上版本的特性，可能会使代码难以维护，因为需要使用旧的、可能已经被淘汰的工具和方法。

但提出的这些观点能不能得到开发者的赞同，因为这并不意味着必须盲目追求使用Java 8及以上版本的特性。在实际开发中，应根据具体的需求和场景来选择合适的工具和技术。在一些简单的场景下，使用旧的特性可能更加简单和直观。因此，在选择是否使用Java 8及以上版本的特性时，需要权衡各种因素，做出最优的决策。

如果CR提出的问题不能有效的说服对方，会对个人影响力造成伤害，以至于对工作的开展起到不利影响。

CodeReview的这些挑战，对CR同学的能力提出了很高的要求，在工作中，需要不断去打磨这个能力。