代码检查的基本原理就是相信人脑（而非人眼）是判断代码好坏的最好工具，比如如果代码中有一行：if(i==1001)returndie()的错误或非法代码，几乎无法经由测试包括自动测试发现，但肉眼却一目了然。
笔者曾编写过一个“复杂而彻底”的代码检查培训教材，但后来发现过于复杂而且还不彻底，所以作罢。下面将要介绍的是一种业余但却有效的代码审查方法。
-----------------------------------------------------------------------
程序员的质量观
有人曾把程序员分为四级：编写可用软件（大致是大学在校生的状态），编写可靠软件（大致是好一些的职业程序员的状态），编写精美软件（在简单性/可维护性/可复用性上有所突破），编写思想深邃软件（设计模式、MVC、JQuery及早期OLE、RPC等创始者所做的事情）。
但在现实中，却往往发现很多程序员停留在第一层次：“你测吧，测出缺陷来我改”“这个不用改也能运行”“这么编就是难读点而已”，师徒间的代码检查，就是把程序员从第一级别向上提高的过程。
第一段提到的25个程序员+1个测试人员的团队是01年我们所在的团队，当时保持了良好的质量风气。尤其由于大家知道没有测试人员擦屁股，留下缺陷相当于给自己找麻烦，所以大家不得不习惯自己动手防患于未然。这个产品后来发展势头很好，07年曾占据市场60%（之后不详）。
怎样检查
一般而言，大致每天高手能编写100多行有效代码（按分号计数），新手会多一些但也不超过200（他们编写代码比较费），也就是10个屏幕以内。有经验的人一定知道：高手看新手的软件，5秒钟就能发现问题。
常存在的一种情况是高手“看不懂”新手的代码，当然不是因为技术太精妙了，而是写得太乱了。但在松结对编程里边不存在，由于师傅徒弟天天在一起，这200行代码可谓一目十行，如果以往一直每天检查代码，那么里边存在的问题应该不会很多。
检查什么
这个是重点，整体包括：
1.结构问题
代码最大的问题，不是一两个地方有技术缺陷，也不是业务逻辑错误，而是整个软件编写的不好。前两者都可以通过测试或使用来发现和更正，但后者就不同了。如果回想一下自己见过的各种烂摊子，是不是有同感？具体哪里有问题怎么改说不上来，就是整个软件看上去混乱无章，无从下手。
具体结构问题包括：重复拷贝代码（不封装函数，不用Template/泛型……），函数过长（超过一屏幕就叫过长），错误封装（不恰当的public/不用Interface/不内聚/强耦合/在类中封装了无关方法……），内容错误（多个无关类置于一个文件/不恰当的命名……）等等。
改正结构问题，是从编写可靠软件向编写精美软件迈进的重要方法。
2.业务逻辑问题
就是软件是否与需求的要求符合的问题。师傅和徒弟经常对业务需求的理解有差异，借此机会同步一下，必要时引入PO（产品经理/策划人员……）。
有人会说业务逻辑问题不是一测试就知道了吗？可是测试一般发生在很久以后，有些逻辑测试还需要一定的触发条件，而且测试只会发现失效（failure,与预期不符）而不能发现缺陷（defect,具体哪里出了错），等积累长了，谁也找不到原因了。
3.编程素养问题
很多问题属于那种“这样也行那样也行”的状态，比如命名/初始值/缩进/断行……但是高手的做法总是比新手好一些。
比如boolresult=true;这句话就有问题，刚初始化就先宣布成功，必有隐患。这是一个真实案例，而下面也的确有一个分支错误地返回了这个true（实际案例是个HRESULT）。而发现这个问题，不是测试而是代码检查。实际上测试几乎发现不了这些问题，比如上面那段代码会在某文件打不开的时候错误地返回这个true，而在测试中几乎不会故事破坏那个文件来测试其结果。
实际使用时，不用拉太长的清单，师傅能想到的看到的告诉徒弟就行。
徒弟不需要学到天上去，只要能学到师傅那么好就可以了。之前在做CMMI咨询的时候我弄过一些检查表，推广均以失败而告终。那些表都是为了顶级安全性的软件考虑的，在普通项目里边使用是个灾难。
几个问题
1.师傅天天检查，会不会很累？
2.不会饿死师傅吗？
会，也不会。如果师傅止步不前，即使他不教别人，也迟早被人超越；师傅也是需要学习的。事实是会教徒弟的师傅才会学习，而会学习的师傅才会教徒弟。
3.师傅跟谁学？
师傅作为高级技术人员，还享有机会外出培训/采购图书等待遇。
师傅自学也很重要，经验更是不可取代的。前事不忘后事之师，要把自己的经历和别人的经历都当作经验来看待。
4.师傅努力编好自己的软件不久已经有很大贡献了，为何要帮助徒弟？
软件整体是一个串联系统，一个环节出了问题整个软件崩溃（Web软件好一些）。因此软件质量取决于最差的部分，而不是最好的部分。
------------------------------------------------------------
从工作层面讲，代码检查使得代码的质量尤其是结构质量，整体上保持在师傅可能达到的水平，从而保证了项目的成功。
至此所有实践层面的内容基本上都写完了，下一篇将提到一些“139团队”的问题，所谓“139团队”就是一个使用松结对编程工作方式的大型团队。