老外的代码走查
有一篇关于代码走查的漫画，一屋子程序员在一起做代码走查，在屋子外面的人数一数 WTF 出现的频率，大概就知道走查代码的质量水平了。WTF 可能有点夸张了，但是这至少说明一件事情——这一屋子程序员至少是真的在审查代码并对代码的水平给出了自己的意见。
我们的代码走查
很难想象我们的代码走查会充斥着 WTF ，因为我们的代码走查都很 和谐 。
我经历过的大多数代码走查都是这么过来的：开发人员把代码写完并已经调试通过了，然后不管是为了满足团队的验收准则，还是因为项目有强制要求，反正找几个同事一起看看，大致流程就是接上投影仪，然后从第一行开始往下念，这里是在干什么，那里是在干什么，正常情况下参加走查的同事大概能坚持个十来分钟不走神，然后眼神就开始迷茫了，等所有代码念完，象征性的提几个大小写或者格式对齐的问题，然后记录到excel里面，大功告成。
代码走查为什么没有效果
为什么我们的代码走查这么和谐呢？看起来并没有起到应有的效果？真是让人百思不得其解的问题。
而在后来和其他的 team leader 沟通时才发现原来所有人都有同样的疑问
为什么代码走查的效果一点都不好？
带着这个问题参加了一场又一场的代码走查会议之后，我找到了下面两个可以说服我自己的答案：
- 避免冲突：长期中庸文化熏陶让我们下意识的避免冲突，在会议中指出他人的代码问题会让所有人都不舒服，多一事不如少一事
- 代码可读性不高：即使我们能够说服所有人相信走查代码并不是针对个人，并消除掉所有的顾忌，但仍会因为代码本身的问题导致走查的效果不理想
代码可读性的问题相对于中庸之道更加隐蔽。代码走查本质上就是在读代码，如果代码的逻辑层次不清晰，命名混乱，依赖复杂，就会让人难以理解，更谈不上去发现隐藏在其中的bug了。不妨将待走查的代码设想为一个小 baby 的玩具房间，第一个房间刚刚经历了熊孩子的大闹天宫，第二个房间刚刚被勤劳的妈妈整理收拾干净，如果我们的目的是从两个房间里找到一件特定物品，我想大多数人都会认为第二个房间更加容易。
而且两个问题产生的影响还会叠加——首先，演示代码的同事看起来并不希望有人质疑他的设计，其次，这些狗屁不通的代码我完全不知道是在干啥，所以，我还是抽空刷一刷朋友圈吧……
应对之道
一，让我们不要那么中庸
中庸——这种传统的东方智慧可以帮助我们在处理很多事情时得心应手，不像西方人那么死板，但是软件开发行为以及衍生出来的技术和管理实践都是根植于西方哲学（如信息论、控制论），这种价值观的冲突让东方的程序员在实施代码走查之类的实践时出现各种不适应。
这种不适应是无法在短时间内扭转过来的。我们从出生起就一直在东方哲学的指导下生活，虽然很少有人意识到它的存在，但是几十年的耳濡目染早已深入骨髓。认识的一位管理教练曾经说过一句话让我印象深刻，“改变一个人是很危险的，但是我们可以改变他所处的环境”，我想为了让东方程序员适应这些实践，大概也只能通过下面这些改变环境的办法慢慢来了：
- 营造安全的技术环境
明确地声明代码集体所有权会是一个好的开始。确保任何人可以修改任何一段代码，并且鼓励将代码重构的更好的行为，鼓励面对面的方案讨论，避免每个人负责小一块代码，避免局部范围的技术垄断。当尴尬或者负面情绪出现时及时发现和化解（比如可以重申代码集体所有权的原则）。 - 种子选手的示范作用
在代码走查会议中，经验丰富且具备强烈责任性的开发人员是优秀的种子选手，邀请或鼓励他们对代码提出自己的看法，发起讨论，其他人会自然参与进来。 - 让所有人看到这真的管用
当讨论发生后，要确保讨论形成可以落地的结论，如果有更优的设计就坚决抛弃掉现有的代码并按新设计进行重构，即使仅仅是提出更准确的变量命名也应该在代码走查会议上当场重命名。
二，让代码具备走查的基础
心仪的女神到家里做客，邀请女神参观房间之前我们肯定会先收拾一下，同样的道理，在代码拿到会议上进行走查之前，我们也要先确保代码进行了初步的收拾，比如没有违反团队的编码规范，检查了内存申请和释放是否匹配，异常也正确的进行了捕获，这些动作可以通过约定 Check list 来进行自检，避免走查会议的时间都浪费在这些细枝末节的争论之中。
代码走查应该聚焦于功能实现的完整性和代码架构的合理性，关于第一点本文暂不涉及，代码架构的合理性又由很多因素决定，比如语言、架构、设计模式等等，在《重构》一书中 Martin Fowler 整理了很全面的技巧，在本文中我想重点介绍的是如何控制代码的逻辑层次来提升代码的可读性。
TBD...
三，工具和其他
- 一个顺手而强大的 IDE 可以大大降低重构的成本（如 Eclipse），让开发人员重构代码时行云流水，满满的成就感油然而生
- 经验丰富的会议主持人，保证代码走查会议是在互相尊重的氛围下进行，确保合理的会议时间安排（时间不宜太长，根据走查的代码灵活安排走查的重点）
我们搞敏捷实践，不管是 scrum xp KANBAN 精益 ，每一种方法都有一套具体的实践，这些单个的实践之间其实是有关联关系的，很少能独立存在，拿代码走查来说，如果团队缺少集体认同的代码规范，或者对CleanCode的理解或价值存在不一样的认知，没有集体代码所有权的意识，没有拥抱变化、互相尊重的心态，缺少实现高扩展性代码的能力、重构的能力，那么做集体代码走查就很难做好。而一旦做不好，团队反过来就会质疑做这个事情的意义，一旦我们对敏捷实践开始质疑，那我们在实施的时候就会更加随意，按《第五项修炼》里的心智模型，这就是一个典型的正反馈系统，这个正反馈系统一旦形成，我们的敏捷转型失败就只是时间问题……
