“白乐天每作诗，问曰解否？妪曰解，则录之；不解，则易之。”

困惑

代码走查是一个团队一天工作中或多或少都会经历的，大体是一群开发者围绕一份代码进行“鉴赏”，形式千千万万，目的却只有一个——让被审查代码在团队内形成“共识”。这种共识包括对故障的识别、对性能的优化、对问题的思考以及对优雅实现的认可，总结起来便是亚旭教练对代码走查原则的一句话要求：代码走查是为了写出更好的代码。

现实让人尴尬

理是这么个理，可实际的代码走查常常会遭遇各种花式尴尬场景：

• 团队每天都会提交不少代码，可一到代码走查时却没人愿意走查。新员工怕出糗不敢走查，老员工盘算着“等写完再一起走查”，然后就忘记了，或是“这次的修改只是个小case，不用看，完全no problem”；
• 代码走查时没人发表意见，无论代码是好是坏。要不是代码好坏傻傻分不清，要不就是认为“大家都是这么写的应该不会错”；
• 团队制定了代码走查清单，但走查时却成了摆设。大家都一下子扎到了业务逻辑里面，却忘记一些唾手可得的规则，比如命名规则、表意清晰等，而这种忘记清单存在其实表露出团队并不认同清单内容，所以清单不会有用；
• “积攒”的代码数量太多，一次走查看不完。这其实是个伪命题，没有上面的问题就不会“积攒”起多到无法走查的代码。

上面这些场景发生的次数多了，团队就会对代码走查产生困惑：“搞代码走查究竟图个啥，啥也学不到又看不出个好坏，还费时费力，不搞不是一样能交嘛”。

如果存在这样的困惑可能真的要认真回顾下代码走查的初衷，再检查下代码走查的姿势了。初衷自不必多说了，如同武功心法口诀默念500遍即可，而这姿势却如同武功套路，还需讲解透彻并勤学苦练才行，下面就聊聊关于姿势的话题。

姿势

正所谓“姿势不对，全部浪费”，代码走查过程究竟要关注哪些要点，又有哪些注意事项呢？这得分成两个角色来看。

讲解者

通常是代码的原作者，负责展示和讲解代码并兼回答其他人的提问。他的首要任务是说清楚下面这些信息：

• 修订要解决的是什么问题？（Why）
• 修订实现思路是怎样的？（How）
• 修订中的代码流程是什么样？（What）

在这之后才是对具体代码的解读，以及与参与者之间的互动。从观察到的走查情况看，上来就讲代码是怎样怎样如何如何的，恐怕参与者大概率是会懵的，因为他们很多人并不了解修订产生的前因后果，如果让他们一直处于懵的状态，那么后面他们既不会关心讲了什么更不会发表意见。

走查者

我在前面的几篇文章中提到过，代码作者是代码的权威，只有他（她）清楚当时写下这段代码时的考虑和感受，其他人只能是从侧面猜测代码的意图，因此走查代码时是一个绝佳的学习机会，与代码作者进行交流，去了解代码作者的想法，最终完善自己对代码的理解。

走查者的职责简单地说就是望、闻、问、切。

望闻问切

望是指观察代码本身的风格、样式、结构，具体包括方法/函数命名是否容易理解、是否符合领域惯例，分支/循环是否嵌套过深等。通常它是最基础的检查，目的是要让团队从简单的规则入手，先“开口说话”，非常适合使用团队制定的走查清单。望的效果要做到“老妪能解”，使得走查者能够理解作者的意图，对于不易理解的就应该作为走查的问题记录在案。

闻是指追踪代码的“坏味道”，比较典型的是重复的代码，霰弹式修改，过多的注释等。无论是走查者还是代码作者，“坏味道”是需要防微杜渐的，却又总是容易无意识流露，很多走查都会在这里停步，很大程度是因为别人犯的错误自己也在犯，所以意识不到错误。闻的要求高于望，通常团队中资深的开发人员或者Tech Leader可以承担闻的工作，更要在闻之后说明问题的根因、识别与防范的技巧。

问是指启发思考和识别问题，以问问题的方式引导代码作者及其他参与者思考。这种问题涉及面比较广，可以是代码架构的，也可以是业务逻辑的，比较常用的句式有“如果...这块代码需要如何调整？”，“这块代码...，是否还有更好的方式来实现”等，目的是让代码作者及其他参与者思考什么是更好的实现、更好的代码。一般到了这一步，代码作者和其他参与者通过简单地引导就会自行发现更合适的实现进而调整现有实现，这就是一种良性互动产生的积极效果，是希望代码走查真正给团队带来的变化。

切是指演示，当上面的三步不能奏效时，适当演示就是必要的，用代码把想要表达的意思呈现出来，更加直观地进行比较。不过切更多的是侵入式的，参与者会暂时地接管讲解者的身份，所以对于切需谨慎使用，在关键之处（大家都懵的时候）投放，而不是频繁使用成为一种炫技的行为。

结语

团队做好望、闻、问就能获得一次富有意义的代码走查，就算是望、闻也能让参与者有所收获，想要尽快摆脱尴尬的走查就要牢记初衷，运用姿势，剩下的就交给团队自由发挥，他们能决定他们自己的走查需要关注些什么。