Technology 技术 Development 开发
快速响应的增量式开发
文 I Steve Freeman, Nat Pryce
作者受到客户委托，开发一个应用程序，能够自动在拍卖中出价。他们勾画出
它的工作方式和主要的组件，同时大致计划了增量式的步骤，来开发这个应用
程序。
从头开始
我们是 "Markup and Gouge" 公司的一个
开发团队，这个公司在专业市场上购买古董，
再卖给"最有品位的"客户。 "Markup and
Gouge" 二直紧随行业的发展，现在有很多购
买是在网上实现的，大部分来自 Southabe白，
这是一家令人尊敬的拍卖行，主要发展在线业
务。问题是我们的买家要花很多时间人工检查
拍买的状态，并决定是否要出价，甚至有时会
·拍卖行是主持拍卖的机构。
这些讨论生成了一份很长的需求清单，例
如能够针对几组相关的物品出价。没有人能够
及时交付所有的需求，所以我们提出了一些选
择方案，买家们不情愿地同意了，因为他们宁
愿先有一个能工作的基本应用。有了这个基本
应用之后，我们可以使它变得更强大。
在线系统中每件物品都有一个拍卖，所以
我们决定使用物品的标识符来指代它的拍卖。
在实践中，我们也发现组击者应用不需要关心
错失一些很有吸引力的物品，因为他们不能够 购买的物品的管理，因为其他系统会处理支付
快速地响应。 和交货。
经过激烈的讨论，管理层决定委托开发一 我们决定把"拍卖祖击者"写成二个Java
个"拍卖姐击者 (Auction Sniper) 软件 Swing应用。它将运行在桌面上，允许用户同时
这个应用程序将监视在线拍卖，并在价格变化 对多件物品出价。它将显示正在扭击的物品的
时，自动以高一点的价格出价，直到达到价格 标识符、价格上限、当前的拍卖价格和状态。
'上限或者拍卖结束。买家们对这个新应用程序 买家可以通过用户界面添加新的组击物品，并
很有兴趣，有些人同意帮助我们澄清要做的
东西。
我们开始与买家小组探讨他们的想法，然
后发现，要避免氓淆就需要对一些基本术语达
成一致意见。
·物品是能够标识并购买的东西。
·竞拍者是对购买物品有兴趣的人或
组织。
·竞拍出价是指二个竞拍者愿意为一件物
品支付某个价格。
·当前价格是物品的最高出价。
·价格上限是竞拍者准备为一件物品支付
的最高价格。
·拍卖是管理一件物品竞拍出价的过程。
根据拍卖行的事件修改显示的值。买家们还要
与易用性设计人员继续讨论，但我们已经同意
大致的版本如图l所示。
"棉田嗣- ~卫:
' …ι…"……一」→~一1 悔h鱼 l 、 崎岖，ι_1. 陶'昭雪睛萤 ,... J!酣'一 …i ~一←…一~→，123 ;81哩W 一 I~悦拘，，-阳咽](:'-d!f理… - 一一 J
凰..c_
... 唱-自. :'
豆盈盈J ... 出画每二
ffll 19-1民m.户ifilff
115
rechnology 技术 I Development 升发
116
第-个用户界面 个状态机，表示了祖击者可以执行的转换。基
这显然既不完整，也不漂亮，但足够让我 本上，犯击者加入一次拍卖，然后经过一些轮
们可以开始工作了。 次的出价，直到拍卖关闭，此时犯击者可能胜
O~
f飞一二s XMPP 飞ι一一~
马/l户?行
事件
æ2 $outhabee' $#;'症结'$卖'$iIi
在进行这些讨论时，我们也与Southabe出
的技术人员交谈，他们为在线服务提供支持。
他们发来了描述拍卖出价协议的文档，这个协
议使用 XMPP (Jabber) 作为底层通信层。图
2展示了它处理多个竞拍者通过XMPP向拍卖
行发送拍卖出价的情况，我们的组击者应用
将成为一个竞拍者。在拍卖进行时，如果某
人的出价提升了当前的价格，或拍卖关闭 ，
SOllthabee's~等向所有连接的竞拍者发送事件，
告诉他们。
与 」次拍卖涵信
拍卖协议
竞拍者和拍卖行之间的消息协议很简单。
竞拍者发送命令，可以是:
Join (加入 )
竞拍者加入一次拍卖。 XMPP消息的发送者
确定了竞拍者，聊天会话的名称确定了物品。
Bid (竞拍出价〉
竞拍者向这次拍卖发送竞拍出价。
拍卖发送事件，可以是
Price (价格 〉
拍卖报告当前接受的价格。这个事件也包
括下次出价的最小价格增量，以及出这个价的
竞拍者的名称。当竞拍者加入时，拍卖会向他
发送这个事件:当新出价被接受时，拍卖会向
所有竞拍者发送这个事件。
Close ( 关闭 〉
拍卖宣布它已关闭 。 最后出价者赢得此次
拍卖。
我们花了 一 些时间来阅读文档并与
SOll t h abee's的在线支持人员交谈，整理出了一
利或失败， 参见图3。我们这时还没考虑上限价
格，以使问题保持简单。
拍啤关闭
拍卖1;rtI
价格‘二出价
!IJ:J J曹1fti!t$<;!:王坊再rlXi草步为-1‘tfitJl!l
XMPP~肖，凰
Soutbabee's在线也将它们使用的XMPP消
息的详细格式发送给了我们。这些格式相当简
单，囚为它们只涉及一些名称和值，并以键/值
对的方式序列化在一行里。每一行都以协议版
本号开始。这些消息看起来是这样的:
SOLVersion : ; COIT,mand : JOIN ;
SOLVersion : l .l ; J:; vent : PRICE ;
Curre~tPrice : 192 ; Increment : 7; B1dder :
Someone else ;
SOLVersion : 1 . 1; Command : 8ID ; price :
199 ;
SOLVersion : 1. 1; Event : CLOSE;
SOlltbabee's在线使用登录名称来确定要
拍卖的物品，所以要竞拍标识符为 12793的物 、
品，客户端会在Sout b abee ' sBII务器上与"用
户" auction-12793聊天。服务器可以通过调用
者的标识符来分辨谁在竞拍(假定账户都已事
先建立好了)。
安全实现目标
即使是这么小一个应用也太大了，不能够
一步完成，所以我们要大致弄清楚实现目标的
步骤。增量式开发的关键技术就是学会将功能
切片 ， 这样就能够每次构建一点。每一小片功
能应该有意义，并且足够具体，这样团队就能
够断定何时它已完成。每一小片功能也应该足
够小，专注于一个概念，并能够很快地实现。
将工作划分为小的、内聚的部分，这有助于管
理开发的风险。我们得到定期的、具体的进展
反馈，所以就可以在团队发现更多的领域知识
和技术知识时，调整我们的计划。
我们眼前的任务是弄清楚组击者应用的
一系列增量式开发步骤。第一步绝对是我们
能构建的最小特征。这里，骨架将以最小的路
径串起Swing 、 XMPP和我们的应用 g 它仅仅
是足够显示我们可以把这些组件组织在一起。
后面的每-步都为己有的应用添加了一层复杂
性，建立在前面工作的基础之上。经过一些讨
论之后，我们得到了要构建的特征序列，如下
所示:
单个物品:加入、不出价、失败
这是最开始的情况，我们将核心的基础设
施放在一起。
单个物品:加入、出价、失败
在基本连接中添加出价。
单个物品:加入、出价、胜利
区分谁发出了领先的出价。
显示价格细节
开始填充用户界面。
多件物品
在同一个应用中支持竞拍多件物品。
通过用户界面添加物晶
通过用户界面实现输入。
在上限价格处停止出价
使坦击者算法更智能。
在这个清单中，买家们把用户界面的优先
级放在上限价格的优先级之上，部分是因为他
们想确保对应用感觉舒服，还有二部分是因为
如果没有用户界面，添加多件物品，并且每个
带有上限价格是不容易的。
任务
单个物品 z 加人、不出价、失败
单个物品:加入、出价、失败
单个物品:加入、出价.胜利
显示价格细节
事件物品
通过 GUI 添加物品
在上限价格处停止出价
æ4 il1A幸if:td
当这些功能稳定后，我们就可以处理更复
Technology 技术 I Development 开发
杂的场景，诸如在竞价失败后重试，或使用不
同的竞拍出价策略。但目前来说，实现这些功
能就够我们忙的了。
虽然不知道这是否就是要采取的步骤顺
序，但我们相信需要全部这些特征，并可以在
做的过程中再调整。为了保持注意力，我们将
计划写在一张索引卡片上，如图4所示。
这1~址贞的
现在您可能对我们跳过的实用性提出反
对。我们之所以对过程进行了简化，目的是既
让您感觉真实的项目是如何工作的，同时又保
留了限制。特别是:
·这不是一个实际的架构 XMPP既不可
靠，也不安全，所以它是不适合来做交易的。
确保这些晶质都不在我们考虑的范围之内。也
就是说，不论底层的架构是什么，我们描述的
基本技术仍然适用。(再说，我们看到过主要
的一些系统构建在像HTTP这样不合适的协议之
上，所以这可能不像我们担心的那样不切
实际。)
·这不是敏捷计划:我们快速通过了项目
计划阶段，得到了一份任务清单。在实际项目
中，我们可能耍了解所有的交付产物(发行计
划)之后，才能动手工作。其他书籍中有关于
敏捷计划的很好的介绍，如[ Shore07] 和
[Cohn05]
国这不是实际可用的设计:好的用户体验
设计会调查最终用户真正想做的是什么，并据
此创建一致的体验。用户体验社区与敏捷开发
社区已经一起工作了一段时间，探讨如何迭代
地完成这项工作。这个项目足够简单，所以我
们可以简要说明想要实现的目标，然后就朝着
目标开始工作。@
川‘四1
测试驱动的
菌向对象歌件开发
G
·飞，-;;;:-._.~
凹'
本文节选自机械工业出版社《测
试驱动的面向对象软件开发》一
书。该书用丰富的代码揭示TDD
和OOD之间的共生关单。特此
感谢机械工业出版社。
117
