代码检视相信大家都非常熟悉，质量管理体系是非常重视代码检视的。然而随着软件工程技术的快速发展，代码检视的作用似乎也不再局限于只是走查一些代码层面的缺陷。
越频繁的代码检视，越有助于质量管理，越有助于需求管理！
从华为出来的QM 武老师，现在就职于腾讯，从事质量管理工作。她曾经在Tid大会上发表过在腾讯推广的“代码检视”，谷歌、facebook常用的“提交前线上检视”。武老师追求的是通过技术骨干检视代码，严格控制交付进入集成环节。同时武老师也在追求快交付，规定每次交付的代码不能超过150行，一方面是方便技术骨干进行检视，另一方面也是引导团队将工作拆解，在合适的交付物上快速进入实现、检视、修改的演进，快速的找准方向。通过这种快，大量缺陷在检视环节被发现，极大提升了产品的质量。
笔者在实践中，也在追求快。每个交付被拆解到100-300行代码，团队成员一写完代码，就被笔者要求召开代码检视（上午写完，下午开始，下午写完，第二天上午开始）。通过这种快速的检视，团队在代码检视阶段发现的缺陷远超过往4倍以上，极大地提升了交付质量。
然而笔者在实践过程中发现代码检视的另一个重要的意义，它实现了面向团队的交付。在检视过程中，团队讨论的焦点，其实是需求（低级错误基本被coverity干掉了）。
通过讨论，笔者发现过自己漏掉的不少需求；
通过讨论，笔者发现团队对需求的理解越来越清晰；
通过讨论，笔者发现团员的思维越来越活跃，需求方向越来越准确。
笔者期望通过需求评审、特性澄清让团队理解需求，但效果很差，结果在这种频繁的代码检视中，越辩越明，水到渠成。
另一方面，集体检视的做法，让团队在潜移默化中向“全功能”转变，这个作用无可限量。
集体检视经常被人诟病的一点：团队集体参加，浪费时间。这也是武老师和我发生分歧的地方。武老师认为开会需要召集人员，需要耗费时间，不够“快”，另一方面，则是一个人能完成的检视，让多个人来完成，效率低。我得承认的确还不够“快”（只能尽量快），但是我反对“效率低”这个论断。
在生产流水线上，工人重复拧螺丝增加熟练度，高级工人过来检视一下做的是否到位，非常高效。但是程序员做的工作很少是重复性，程序员从事的更多是创造性的工作，这类型的工作需要思维的活跃，闭门造车，闭关修行绝对不是推荐做法，相反，开放交流才能引古论今，创造未来。
先不说笔者的案例，我们看看团队中常见的情况。菜鸟问老员工某个问题，老员工不耐烦的说看一下代码就行了，这还不会。另一个场景，热心的老员工耐心的教菜鸟怎么解决。两种情况，哪种情况老员工的工作更高效？热心的老员工效率绝不会差。
我们常听到一个词“慢即是快”，停下来总结一下，会让未来更高效。交付压力越大，老员工越没时间去总结，菜鸟的询问是让老员工适时慢下来总结一下。说概念有点虚，我们看案例吧，某咨询公司有一个团队，每个人发20粒咖啡豆，如果别人帮助了你，你就送给他咖啡豆作为鼓励，结果有一个很nice的老员工，很多人都找他，他经常被打断，但他不仅拿的咖啡豆最多，他的开发效率也是最高的。笔者举这个案例，其实想说明一个论点：交流是高效的捷径。
回到笔者的案例，笔者是很想团队交流，但我没钱买咖啡豆^_^。
因此笔者想在集体检视的环节促进交流。问题来了，怎么让大家活跃交流？常见的集体检视，有人在打瞌睡，有人三心二意，唯有代码作者热情洋溢，滔滔不绝。其实我很希望有人能打断作者，即使问再弱智的问题。为什么没人愿意打断作者呢？因为没有利益，作者讲的代码对我没用，我都懒得思考。改进的措施来了！
试想一个球队，如果每个人都坚守自己的位置，各自为战，结果惨不忍睹。但是如果观察队友的动作，去协防，去跑位，结果将大不一样。这是为什么？利益相关，目标一致。笔者的措施是将故事拆解，一个团队扑在一个故事上。“分工明确”滚一边去，我们要集合力量一个个的攻下山头。当每个团员做的事情都非常接近时，阅读别人的代码，实际上也是在梳理自己的逻辑思路，在帮助自己交付。笔者在实践过程中，通过利益让团队喜欢集体检视，让团队喜欢上这种高效思考的感觉，让团队自发的组织集体检视。
效果：团队超过1/8的时间在集体检视，团队的开发效率提升2倍！（还不计算代码覆盖率的大幅提升）
总结笔者的措施：
1、故事拆解，一个团队扑在一个故事上
2、面向团队的交付，必须经过团队集体检视，才能认可交付
3、快交付，刚写完代码，下个时间段就组织评审。
分享者简介
符章文：2005年毕业于中国科技大学，2010年加入鼎桥通信，目前担任研发团队Team Leader兼负责敏捷推广。个人长期从事软件研发工作，致力于研究提高工作效率的方法。对于敏捷十分推崇，经常思考如何将敏捷实践和项目工作结合，提高团队效率，并将实践总结分享
中生代技术群微信公众号
