Thinking in C++ (1-8) 极限编程

极限编程

在上大学的时候，我就开始零散的学习分析和设计的技术。极限编程(Extreme Programming，简称XP)是我所了解的最为激进，最为振奋人心的概念。在Kent Beck的著作《解析极限编程》中你会读到极限编成的编年史。也可以浏览www.xprogramming.com了解相关信息。

XP既是一门编程工作的哲学，又是一系列对编程工作的指南。其中的一些建议来源于近期其他一些方法论的经验教训，但在我看来，极限编程最为重要而且无可替代的贡献在于“首先编写测试模块”和“结对编程”。尽管Beck十分强调整体的重要性，但是他也指出如果你仅采用这两种做法，同样会显著的提高你的工作的效率和可靠性。

首先编写测试模块

测试在传统上总是被放在项目的最后进行，你已经达到了“让整个项目运行起来，仅仅是为了确认”这种状态，测试不知不觉地沦为了项目中的配角，专业测试人员总得不到应有的地位，他们总会被埋没在项目的最底层，他们很难成为“真正的程序员”。而许多测试小组往往就是这样：穿着邋遢，不注重生活细节，而且会为一点点小成果沾沾自喜（老实说，当我研究C++编译器的时候我也曾经那样过）。

XP使测试在项目中拥有了与编码同等（甚至更高）的地位，测试的概念得到了彻底的革新。实际上是这样的，你在你的代码得到测试之前编写测试，然后测试就永远与代码同在。每次对项目进行整合时都要运行一次测试（这是非常频繁的，有时候甚至一天都要做许多次）。

首先编写测试模块有两个极其重要的意义。

首先，它使得每一个类都必须清晰的定义出接口。我经常建议人们在设计系统时，可以尝试“想象出一个完美的类，它可以自行解决一个特定的问题”。XP测试策略的改变更加深刻：它规定了类必须要以何种形态呈现给它们的使用者， 以及关于类的行为的精确信息。一切都是精确的。你可以把一切写的乏味无趣，也可以通过创建图表来描述类的行为和外观，但是只有一组测试才是再真实不过的了。前者只是把期望的结果列在一个表上，而测试则是一个契约，它通过编译器和运行的程序得到强制执行。很难想象出比测试更加具体的方法来描述类。

创建测试时，你将不得不全面的去考虑类，届时你可能会发现类需要一些新的功能，而这些功能很可能会在思维实践（比如UML图，CRC卡片，用例，等等）过程中被忽略掉。

在编写软件的过程中，你可以从一次次的测试过程中体会到首先编写测试的另一个意义。这样做将测试工作的一半托付给了编译器。如果你以这个角度来认识编程语言的进化，你将看到技术上真正的革新实际上是围绕着测试进行的。汇编语言仅仅检查语法，但是C则对语义做出了一些强制规定，这些都会妨碍你犯一些特定的错误。OOP语言对语义做出了更多的强制规定，如果你仔细思考你会发现，这些强制规定实际上都是以测试的形式存在。“这一数据类型是否得到正确的使用？这一函数是否得到正确的调用？”这样的问题就是编译器和运行时系统所进行的测试工作。我们可以看到在语言中置入测试功能的成效：人们可以使用更少的时间和精力，创造出更复杂的系统，使它们可以正常的工作。我曾经怀疑过为什么会这样，内建的测试模块所构建起来的安全防护网会告诉你问题的所在。

但是语言内建的测试功能存在局限性。在某些时刻，你必须亲自介入测试工作，从而构建一套完整的测试套件（与编译器和运行时系统协同工作），此时你的整个程序都会得到完整的验证。正如编译器可以帮助我们承担一定的测试任务，如果自始至终有一些测试模块可以帮助我们，这将是很愉快的一件事。这就是首先编写测试模块，在每次构建系统事都运行一次测试的初衷所在。你的测试模块可以成为语言所提供的安全防护网的一个有力的扩充。

我发现了一个问题，使用越来越强大的编程语言，我们可以更大胆的尝试更加不成熟的项目，因为我知道语言将会防止我在追踪bug上面白白浪费时间。XP测试方案为你的整个项目做出了同一件事。因为你知道你的测试工作将为你找出你所带来的所有问题（如果需要，你也可以按照惯例添加任何新的测试模块），你可以随时随地做出重大的改变，而不用担心系统会被你搞得一团糟。这种强大的特性太令人难以置信了。

结对编程

结对编程(pair programming)反对自由散漫的个人主义，然而这种观点已经在大多数人心中根深蒂固，学校（我们获得成功或失败的地方，在那里与其他人合作被人为是“作弊”）和媒体（尤其是好莱坞大片中的英雄人物总是生性叛逆[1]）都在为我们灌输这一思想。同样地，程序员往往也存在个人英雄主义的思想。Larry Constantine喜欢把他们称为“编程牛仔”。XP虽然是不断地与传统思想作斗争的先锋，但是它却建议一个工作站的代码应该由两个人来编写。这适合于那些有许多工作站的工作场所，那些隔板（人们往往认为它们可以带来方便，并且十分乐意见到它们）实在不应该存在。Beck说XP所需要进行的第一项转变的任务就是拿起改锥和扳手拆除一切挡在眼前的障碍[2]。（但这需要项目经理去平息后勤部门的愤怒）

结对编程的价值在于，一个人在编写代码，而另一个人在思考。思考者在大脑中描绘出一幅整体的景象，不仅仅限于手头正在解决的问题，而且包括XP的一些建议。如果两个人都在工作，那么我们就很难听到其中的一个人说：“我不喜欢在一开始就编写测试模块，”举例说，如果代码编写者遇到了困难，他们可以互相交换位置。如果两人都遇到了问题，他们都在沉重的讨论也许会被周围的人听到，那么此时这第三个人可能就会帮上忙。结对使得工作行云流水。也许更重要的是，它可以促进程序员的相互交流，使得编程工作更加有趣。

我在一些研讨会上的训练期间开始推荐使用结对编程，这十分显著的丰富了每个人的经验。

---

[1] 尽管这一观点更多是以一个美国人的角度出发的，然而不可否认的是好莱坞大片的影响遍及全世界。

[2] 尤其要提出的是PA系统。我曾经在一家公司工作，这家公司坚持广播官员的所有电话通话，这经常会打断我们的工作（但是经理们并不打算取消PA这项十分重要的服务）。最后在没人看到的时候，我把扩音器的点线剪断了。