方法学之RUP与XP

一般我们可以采用RUP的方式来进行开发,即从需求,到分析,到设计,到实现,到测试,RUP从最容易理解的需求开始,然后通过需求导出设计,由设计指导实现,因此,在使用RUP时,最困难的步骤是需求,只有需求分析清楚了,后面的设计和实现就自然的水到渠成。但是RUP的一个缺点是需求要相对固定,因为需求的改变会导致后期的设计和实现的改变,因此对于一个需求确定的项目RUP是一个不错的选择。

另外一种开发方法是XP,他从测试,到代码实现,到重构,然后返回测试,一直迭代,直到实现所有的功能。XP从另外一个侧面来说,也是从需求入手,只不过,她的需求是通过测试来表现,这样的一个好处就是,能够很直接的把类的published方法,而不是public方法提取出来。特别的,对于分层系统来说,测试起到一个模范的作用,测试在测试下层服务的同时,也相当于把自己设置为一个上层服务的角色,因此上层的服务可以模仿测试的语法来调用下层的服务。

一般情况下,我们都喜欢把RUPXP摆在一个对立的立场上来进行比较,而更多情况下,我们都要非此即彼的选择一种方法作为我们项目的开发方法。但是,我觉得这样做完全没有必要,而且不合适。首先,这两种方法都是经过了一定项目实践之后提出来的开发方法,因此,理论上他们都有一定的可取性。另外,这两种方法之间存在比较明显的相互补充特性,这表现在RUP的缺点往往是XP的优点,而XP的缺点却正好是RUP的优点上。因此,在选择开发方法时,我们应该适度的把这两种方法进行糅合。

首先,在开始的时候我们可以采用RUP的需求分析策略,它比XPTDD更加容易入门和上手,因为,在不确实了解需求的情况下,根本不可能提出测试用例。

有了需求文档接下来我们可以开始使用XP中的TDD方法,这里之所以不使用RUP的分析,设计是因为一般来说这两个步骤占用的时间比较长,这就造成了发布时间的延长。而且,相对于文档,代码更有说服力,而且对于程序员来说,代码的意义很多时候比文档要大。再者,对于需求不稳定的项目,测试用例相对于分析,设计文档具有更快的反应速度和更短的反馈线路。因此,在这一步我们采取开发测试用例的方式。

有了测试用例,很自然的接下来的步骤就是代码实现,然后测试,然后重构。标准的TDD方式。

在以上的所有步骤当中,我们都是围绕着程序员在开发,但是,在一个团队当中,除了程序员以外,还有大部分不直接参与编码的管理人员和最终用户,因此,伴随着测试用例还有代码,我们应该根据RUP的方式,提取出对应的分析,设计文档。之所以在这步才完成上述文档主要是基于以下考虑。虽然从需求我们可以导出这些文档,但是由于在那个时候,我们尚未对系统进行任何实现,因此,所有的分析和设计都具有或多或少的猜测和不确定性,因此,在RUP当中,我们需要不停的进行迭代,来对系统进行求精。而使用TDD的方式,一开始我们就从代码出发,而通过测试和重构,我们就能完成系统的求精,因此相对于RUP的文档,代码,文档,代码的迭代求精方式,TDD只需要在代码一级进行迭代,因此从时间和难易程度上TDD都要比RUP要简单。

评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值