讨论与思考

下面的讨论将主要围绕一些XP的实践原则展开。

用户在场（On site customer）

尽管开发组的一部分在客户地点，但主要的开发工作却是在公司本部进行的。这里没有用户，没有业务分析人员。这点显然与XP的原则相违背，而其造成的不利影响贯穿于项目始终。首先是对制订计划与进度表的影响。一般来说，在制订计划之前，开发人员需要花一两天读一个“故事板”，然后作出初步估计。故事板简单易读，能使人很快地大致了解一个功能模块的需求。但是，很多地方比较模糊，有些地方在阅读文档中仔细一点能看出来。这时好有用户/业务人员在场，马上能澄清。象我们靠电话和email，时间花的多，还不见得能说得很清楚。

第二个影响要更严重一些。“故事板”中的不确定性有些在读故事板时能发现，而有些只能到了编码的时候才能暴露出来。由于业务分析人员在客户那边，只能靠电话和email，其质量当然不如面对面的讨论好。特别是当不能及时得到答案而时间又紧迫时，程序员往往得靠经验和“推理”作一些假定。如果是错的话，只能在功能测试和用户接收测试时再改了。

另外一个类似问题是与后端系统通讯的规范说明，这是由另一个项目组提供。那么我们与他们之间也是有个沟通的问题。而糟糕的是该项目组也是在客户那边，因此只能靠电话和email。总之，我觉得这个项目的实践是从反面证明了用户在场的重要性。

制订计划与进度

如上所言，制订计划和进度表是从阅读“故事板”和规范说明开始。经过若干电话与email的往来后，制订出一个计划，主要是把需完成的模块进一步分解成一些任务，以及估计完成每个任务要花的时间，以0.5天为一个单元。该计划是一个spreadsheet文件，放在项目的文档服务器上，大家随时可查看。

“并行开发”

我们的项目有一点和正规的use case driven的过程不太一样。一般是一个周期主要是做一个 use case。在我们项目中，一个“故事板”大概算一个use case。如在“工作笔记”中所言，在项目走上“正轨”后（从第六周开始），一般是2－3人做一个“故事板”。所以，一般同时可能有两三个“故事板”在进行。每个“故事板”的周期约3－4周。这样做的好处是提高了生产率，但我觉得这样做的前提条件是每个开发人员必须是有足够的经验与技能，还有是熟悉开发过程（第4－5周的实践是非常重要的）。

单元测试

单元测试是客户的一个要求。在前两个月，我们做还有些“过分”。我们是用NetBeans提供的工具对每个类（class）都生成相应的JUnit测试类（test class）。对一个类而言，其中的每一个 public和protected method都在test class中有对应的一个test method。而这个test method 里只有一个fail语句。这样强迫你用测试来替换这个fail（当然你也可以把它删掉）。结果我们发现花了很多时间去写getter和setter的测试，实在不值得，因为这些methods非常简单。我们因此说服客户，允许我们不用对getter和setter些测试。不过，我倒是发现，对 getter的测试，实际上是在测试相应attribute的初始值。设置初始值常常被忽略，而会在运行中引起一些问题，如常见的 NullPointerException。

单元测试通常要求把被测的对象孤立起来，即测试不要用到其他的类。而实际中，一个类往往要用到其他的class提供的服务来完成自己的功能，常见的如使用数据库或一个远程服务。单元测试需要切断这种依赖性，即一次只测试某个我们需要测的类。这可以利用Mock Object （“模拟对象”）技术来达到，例如，用一个mock service来代替真正的service，而我们可以很方便地对这个mock service进行状态设置。在我们的单元测试中大量地运用了这种技术。网上有一些工具可用来帮助产生mock objects，如MockMaker，可以节省一些时间。

总的来说，单元测试的确提高了源码质量。那些逐步建立起来的test cases，我感觉是起到了一张 “警戒网”的作用。源码修改需要作改动时，这种作用特别明显。不过，我们也注意到，对一个类进行完整的单元测试所花的时间往往不少于编码的时间。因此，一个很重要的问题是决定测试到什么程度。XP的建议是对“可能会出问题”的地方要重点测试。但什么是“可能会出问题”的地方则需视具体情况而定。

系统集成与功能测试

由于我们这里没有一个真正的后端系统，因此没办法作真正的集成与功能测试。在项目的前半期，我们曾建立了一个“哑”后端，这的确对我们的测试/调试起到了很大作用。但是，当越来越多的功能加入后，“哑”后端变得越来越负责和不可维护。后，我们只得放弃这种做法。

项目的管理层曾作了很大努力，想使我们这里能直接连上客户那里的后端系统，这在技术上是完全没有问题的（毕竟这是网络时代）。但不幸的是，这个合理要求没能得到满足。所以项目后半期，当一个“故事板”的的编码与单元测试完成后，一般由编码者或测试者飞到客户那里去做集成与功能测试。

结对编程（pair programming）

在我们这个项目的实际中，pair programming与“传统”上的意义有些不同。首先，因为我们坐得都很靠近，如果某人有什么问题，只要一叫，一般会有人跳起来跑过去帮忙。这可算是一种 “基于解决问题”的pair programming。

另外一种更主要的是方式是编码与单元测试的结对。由于测试者对于如何使用一个（待测试）的类一般不会有着与编码者完全一致的思路，这样对于发现问题是很有帮助的。另外，由于测试者一般都会在测试时详细阅读源码并与编码者讨论，这对于改进一个class的细部设计与实现也是很有用的。但这种审阅与源码有所不同，这里主要是着重“逻辑”的正确与有效，而源码审阅则偏重于源码的风格与标准的统一。

还有一种方式可称之为“结对排故”（pair debugging），我发现这种情况多在系统功能测试中出现。如果在测试中出现一个问题（bug），找来找去找不到（因为这时涉及的东西的较多），搞得昏头胀脑。那么好是抓一个同事到屏幕边上（好不是和你搞同一个部分的），然后给他讲讲是怎么回事。他可能会一眼看出问题所在（如果他曾遇到过类似的问题），或者会从另一个角度来提供一个思路。另外，常常也有这种情况，来帮忙的可能只是听着，而你在讲的时候可能自己发现问题了。我想这是因为你在给其他人解释一件事的时候，你实际上是在强迫你自己清理自己的思路，而这肯定是有助于找到问题的（特别是在昏头胀脑的时候）。