拔剑吧，诸君！

在探讨完代码走查的“姿势”和“周边”后，终于要和如何落地代码走查见面了，如果说以前聊的还只是一些理论、招式的话，现在就轮到探讨一些“家伙事儿”了。

工具

市面上代码检查工具不少，例如klockwork、sonar、checkstyle等，可它们并不能替代代码走查。相比代码走查，工具存在一些弱项：

• 缺少语境，工具并不知道代码应对的领域，因此对于代码“合适”工具无法理解
• 缺乏交流，前面提到过代码走查是一项需要“碰撞”的集体活动

两者的目标是不一样的，工具是为保证代码“合规”，而走查是为保证代码“更好”，所以工具适用准入，而走查适用准出。这里其实涉及到了一个“走查”职责的话题，有种观点认为走查能够检查代码中的缺陷，我不否认有时候确实能发现一些疏漏，但依靠这样的检查实际上有点“掩耳盗铃”。代码是不是正确应该是开发者来保证的，可以依赖各式的xUnit或者更大颗粒度的测试框架，如果代码功能不正确是没有必要进行代码走查的，因为你不可能让一个错误变得更好只能变得更错。

虽然工具不能替代走查，却可以提升走查效率。随着工具的升级，有些走查内容可以借助工具输出，例如代码行数、命名风格、重复代码等。在代码走查之前就消除掉这些问题，这样在代码走查时我们就可以探讨一些更高级的问题了。

清单

清单

把前面文章中的观点进行整理后，大致能够获得这样一份代码走查清单，其中包含了可参考的走查维度，包括理解、结构和场景。

理解，原则就是表意清晰，并且符合领域惯例，因此不妨考虑以下走查项：

• 测试方法定义能够清晰地说明测试功能点；
• 测试方法使用了正确的断言验证；
• 产品代码中类、函数、变量定义无二义性（以团队理解一致为验收准则）；
• 产品代码中类、函数、变量定义使用领域术语（由领域专家或业务专家判断）；
• 产品代码中数据、方法归属合适的类持有，封装良好；
• 产品代码中多个并列语句表意清晰，逻辑运算易于理解。

结构，原则是修订不应对代码整体产生结构性破坏，可以通过观察和提问的方式来尝试以下走查项：

• 修订在同一类中是否存在结构性重复；
• 修订在多个文件中是否进行了相同的修改；
• 修订是否破坏了原有类、方法的封装性，是否可以将修订使用新的类或方法封装；
• 修订是否与已有代码存在逻辑上的并列、叠加以及组合关系，是否可以进行归类或抽象；
• 修订在同一方法中是否引入了较多的分支。

场景，关注代码的可拓展性也可视作代码结构对新增场景的抗冲击能力，OCP原则是一个非常好的参考标准，所以对于场景更多的是通过一些提问来启发思考，以下有一些典型问题可以参考：

• 当新增一种（类型/场景/设备等）时，代码结构需要如何调整？
• 当要求并发时，代码结构需要如何调整？
• 当引入一种新的分支条件时，方法需要如何调整？
• 当要兼容新旧（版本/数据）时，方法需要如何调整？

需要注意的是对于场景的提问应当立足于当前实现，尤其是针对可以预见的需求，而不应漫无边际地拓展，从而跌入过度设计的泥淖中。

运用

光有理论、工具和清单是不能拥有一次好的代码走查的，你需要的是运用，但在实际中总会有尴尬时刻，比如提议代码走查却无人响应或是代码走查成了个人脱口秀等。如果你遇到了这样的尴尬，不妨试试下面的技巧：

• 安排一位走查主持人，可以Scrum Master或其他志愿者
• 走查可以按照提交记录进行，走查前一天的提交代码
• 走查发现的问题要及时记录，并且在下次走查时由作者进行反馈
• 走查优先安排新员工进行

技巧虽小却也是代码走查的一部分，它最终会形成团队代码走查的制度、习惯和意识，并将理论和工具融入其中从而常保活力。

到这我们关于“代码走查究竟该关注什么”的三篇专题就告一段落了，在这三篇专题中我们从“姿势”出发、了解了代码走查的“周边”，最后还获得了“工具”和“清单”，现在你已经拥有了我们所知道的有关代码走查该了解的信息了，现在该怎么做就看你的了！