有所为，有所不为

“写出更好的代码”是目的，不过缺少了主语，是要让谁写出更好的代码？是你，是我，还是参加走查的其他人？显然主语应当是参加走查的每一位团队成员。走查讲解者收获更好代码的可能，提出意见者收获整理和表达代码意图的锤炼，聆听者收获代码实现思维的碰撞，初学者收获代码技巧和缺陷的知识。每个人都能从代码走查中收获，但在这之前却要先放下自己所有的假设，例如团队中并非每个人都有一样水平的编码技能，总有人会差一些，因此当这些人发起代码走查时，其他人就应该放下“他的代码一定很烂”的假设，把注意力聚焦在代码上，既要看到问题也要看到闪光点，最应避免只盯着问题发难而不去启发解决方法，“责难”少一点，建议多一些。

代码走查过程中完成对风格、样式的识别和认可固然重要，但更重要的是交流和碰撞。同样的问题，每个人却会有不一样的解决之法，参与者都应尽可能地将自己的想法充分展示出来，交流的过程也是不断完善自我想法的过程，更有可能创造新的选择。“求同”是代码走查的基础追求却不应当成为终极目标，“百花齐放，止于至善”才是。

积跬步，至千里

代码走查应该从哪里开始？不少团队会紧盯代码的流程、逻辑而很少深究代码是否可读、可测、可维护，所以经常是走查代码时朦朦胧胧地清楚，后面再去维护代码时浑浑噩噩地糊涂。究其原因就在于代码的可读性与可理解性差，没有办法在后续的维护过程中将代码意图还原，尽管“可读、可测、可维护”只是代码小小的“跬步”可却是代码的基础，基础不牢地动山摇的道理应该每个人都很清楚。

推敲

古人写诗有“推敲”一说，写代码同样也需要推敲，虽然要做到“老妪能解”不太现实，但表意清晰符合领域惯例却是可以努力的，例如要实现一个获取方法究竟该如何命名，在不同的领域答案是不一样的。

public Y get(X x) {...} // 一般标准答案

public Y query(X x) {...} // 数据库获取

public Y fetch(X x) {...} // 轻量级获取

public Y download(X x) {...} // 网络获取

这就要求代码走查首先要检查代码是不是“专业”，并且这种“专业”是团队都能理解的，所有人都可以用相同的“专业”术语去描述同一件事物。

当概念复杂时，可以借助测试用例来分解功能，因此代码走查要看测试用例（很多走查不关注），而且检查测试用例就是检查业务逻辑和流程（因为你描述了对它的使用期望）。

如果不想代码永远粘着自己，那就应该想办法提升代码的可维护程度，少一些“绵绵不绝”和“套路”，短促有力和化繁为简才是人间正道。

不积跬步，无以至千里；不积小流，无以成江海。提升代码走查的有效性不妨从这些跬步开始。

行百里，半九十

当走查显示本次修订流程、逻辑都正确，测试用例也印证了这一点时，是不是说明走查就大功告成、完美收官了？我问这个问题你一定知道答案是非也，那为何答案是否定的呢？

形而上学

套用一个哲学词汇“形而上学”就能回答为何答案是否定，所谓形而上学是指用孤立的静止的和片面的观点去看世界，认为世界上一切事物都是彼此孤立和永远不变的。

在代码修改过程中，虽然只针对某个场景或逻辑，但实际上改变了代码的整体，因此有必要纵观上下文去探究一下是否引入结构性的问题，例如重复、霰弹式修改等。这些问题通常不容易发现，因为大多数人都是这样修改代码的，初次的修改通过复制粘贴引入了结构性重复，二次的修改则由于结构性重复触发了霰弹式修改，环环相扣步步惊心。

代码走查要关注本次修改，还应看到本次修改与整体代码的联系，看似正确的修订可能造成整体的结构破坏，看似细致的走查其实遗漏更大的问题，这便是代码走查中要注意“行百里者半九十”。最佳解决方法是培训走查者自身的“嗅觉”和“代码洁癖”，更要在走查时高挂“重复是万恶之源”这把达摩克里斯之剑。