使用极限编程改善项目的设计和灵活性

上传人:kms****20 文档编号:39808379 上传时间:2018-05-19 格式:DOC 页数:13 大小:39.50KB
返回 下载 相关 举报
使用极限编程改善项目的设计和灵活性_第1页
第1页 / 共13页
使用极限编程改善项目的设计和灵活性_第2页
第2页 / 共13页
使用极限编程改善项目的设计和灵活性_第3页
第3页 / 共13页
使用极限编程改善项目的设计和灵活性_第4页
第4页 / 共13页
使用极限编程改善项目的设计和灵活性_第5页
第5页 / 共13页
点击查看更多>>
资源描述

《使用极限编程改善项目的设计和灵活性》由会员分享,可在线阅读,更多相关《使用极限编程改善项目的设计和灵活性(13页珍藏版)》请在金锄头文库上搜索。

1、使用极限编程改善项目的设计和灵活性使用极限编程改善项目的设计和灵活性这个过程会频繁地重复,每次进行测试均是为了保证产品的正确性。设计、编码和测试三者之间的鸿沟将不再存在,这样可以促进你对整个环境更好地理解。因此,你的设计(和编码)将随着项目的成熟逐步得到改善而非降低。使 TDD 更加有效的原因是单元测试自动化,而且这些自动化单元测试的工具可以从 Internet 上免费获得。虽然没有简化功能版的商业产品,但开发人员可以合理地使用这些高质量的软件。本文将指导你怎样获得和使用 Nunit 并通过 C#(或者任意一种基于Microsoft .Net Framework 的语言)开发实践 TDD。注意

2、到类似的工具对于 C+和 Java 开发人员也是可用的,因为他们支持大多数语言和操作系统。这些工具与极限编程紧密地结合起来,扩大了 TDD应用的范围。随着项目的逐渐成熟,难道你不愿意自己编写代码的道路通向坦途,而非走向荆棘丛生的崎岖小径?似乎看起来不管你采取什么方式,编码之路迟早会走向迷 途。项目越大,困难越多。有多少次当你以一个近乎完美的设计开始你的项目,然而一旦开始编码,你会发现自己事实上只看到了项目的局部?测试驱动开发(TDD)改变了编码的过程,并且这种改变不仅是可能的,同时也是值得去做的。开发包括三方面的活动:编写测试用例,编码并进行测试,重构代码以消除重复代码使其更简单、更灵活、更容

3、易理解。这个过程会频繁地重复,每次进行测试均是为了保证产品的正确性。设计、编码和测试三者之间的鸿沟将不再存在,这样可以促进你对整个环境更好地理解。因此,你的设计(和编码)将随着项目的成熟逐步得到改善而非降低。使 TDD 更加有效的原因是单元测试自动化,而且这些自动化单元测试的工具可以从 Internet 上免费获得。虽然没有简化功能版的商业产品,但开发 人员可以合理地使用这些高质量的软件。本文将指导你怎样获得和使用 Nunit 并通过 C#(或者任意一种基于 Microsoft .Net Framework 的语言)开发实践 TDD。注意到类似的工具对于C+和 Java 开发人员也是可用的,因

4、为他们支持大多数语言和操作系统。这些工具与极 限编程紧密地结合起来,扩大了 TDD 应用的范围。为什么设计会降低性能大多数传统软件开发过程是基于你在设计之初正确的设计与估计,并通过开发以形成完美的产品。这种开发方式保证了产品的统一性和之间的最小差异。然而 这一过程却忽略了交流与反馈,同时也不利于生成错误信息(测试失败) ,并因此制定策略采取相应的措施(修复设计) ,而这些正是 TDD 所重视的。为什么我们不能在开始就获得正确的设计?因为在开发时,处于项目之初的我们无法获得有关这个软件完整的知识。迭代式开发虽然也认同这一事实,并帮助 你在项目开发初期识别一些重要的问题,而不是把这些问题留在后期解

5、决。然而,迭代法无法终止开发过程,使你回到设计阶段来解决问题,哪怕这只是因为一个命 名糟糕的公共类名。没有人愿意关注这些细小的问题,且不幸地,这种设计过程也禁止这种更新,因为在各个阶段不停重复的代价太高。传统开发过程中的这些小问题一旦积累起来,会导致大问题的发生。你或许认为与其将时间耗费在这些对功能影响不大的细枝末节上,还不如将精力放在更重 要的环节。然而,这个命名糟糕的公共类在代码中保留的时间越久,则相关的使用也会越来越多,改变起来就越来越困难。之后,团队会在编码的时候非正式地修改 这些问题,很快,在计划发布整个产品时,你会做大量的工作尽量使代码和设计文档保持一致。对于这种情况来说,你之前的

6、设计是没有价值的,因为代码本身就说 明了设计。测试驱动开发允许你推迟决定,直到你更好地理解了问题之所在。当你只是了解到产品开发的一些基本信息时,你不必设计出完美的体系架构。这对于传统软 件开发中已经确定的理念来说,是一种挑战,从某种角度来说,甚至是违反常规的。因此我们建议你以一种开放的思想来尝试 TDD,你会发现 TDD 的强大。TDD 的另一个好处是更容易掌握。你开发的一系列测试说明了代码的运行机制,这种程序自我编档的方式促进了交流。它要求你通过概览测试用例并阅读自 己的代码来获得反馈,从而有利于你创建的对象和组件更趋于松散耦合。同时,TDD 可以推迟你的设计决策,从而简化设计,使你能集中精

7、力修正设计的问题。最 后,它通过给出的一系列测试减轻你编码的压力,因为当测试发生中断时,它可以立即告诉你究竟发生了什么。简介要真正理解 TDD,唯一的办法就是实践。让我们从一个简单的例子开始,这个例子并不要求任何特殊的工具。我们要写一个小程序,来帮助我们规划住宅前 的一块长方形的草坪,但在设计之初,我们需要作两个测试:当长度为 3,宽度为 2 时,计算得到的面积应该为 6;同时计算其周长应该为 10。写下这些测试有助于我们将焦点集中到程序的一些要点。在这个例子中,似乎创建一个对象来模拟问题域是合理的,因此我们创建了一个类,取名为 Quad,来代表我们要建造的长方形草坪,并在一个简单的控制台应用

8、程序中实例化它。下面就是我们实现的步骤:1、启动桌面的 Visual Studio,选择文件 | 新建 | 项目,选择 C#项目类型中的“控制台应用程序” 。为项目取名为“QuadApp” ,然后点击 OK。2、在主函数中输入下列几行代码,创建 Quad 实例,并通过Assert 断言,当长宽各为 3 和 2 时,返回的结果应该是 6。static void Main(string args)Quad q = new Quad();System.Diagnostics.Debug.Assert(q.Area(3,2) = 6);3、选择项目 | 添加类,在对话框中输入“Quad.cs” ,点击

9、“打开”以创建类。4、输入下列代码,创建在 Main 函数中用到的 Quad 类的成员方法 Area:public class Quadpublic int Area(int length, int width)return 0;5、选择生成 | 生成 QuadApp 菜单项,此时编译应该是成功的,然后当你运行该程序时,会报告错误,因为此时返回的面积值不等于 6。6、指定 Area 方法的返回值为 6,再重新编译程序,并运行,此时没有错误发生。7、改变 Area 方法的实现,返回值用输入参数的乘积来代替起初指定的返回值常量。再次重新编译程序,并运行测试。第二个测试(计算周长为 10) ,与前面

10、的方法相似。首先在主函数中通过 assert 写测试代码,接着执行第 4 到第 7 步,只是方法名用 Perimeter 而不是 Area。当你在第七步中试图改变设计时,你可能会得出一个结果,就是可以通过构造函数来传递长和高的值,并将其存储为对象的属 性,而不是通过成员方法的参数来传递。设计改变后的代码如下:public class Quadprivate int m_length;private int m_width;public Quad( int length, int width)m_length = length;m_width = width;public int Area()r

11、eturn m_length * m_width;重新编译程序,并运行之,以保证你在写代码是否因粗心而漏掉了什么。我们通过一种最简单的形式完成了演示 TDD 工作原理的练习。下面是每一步的总结:1、写一个失败的测试:我们选择了一个最容易实现的测试(虽然在这个例子中所有的都很简单)来实现。接下来,我们写了个Quad 类的最简单实现,以保证程序能够通过编译。然而,当我们执行程序时,调试窗口会出现 assert 的错误信息,因为返回的面积值不是 6。2、修改代码以通过测试:要修改代码,首先我们做一个最简单的方法,就是直接返回常量值 6。该值刚好使程序能够运行且通过测试。接着下一个测试必须使用不同的参

12、数值,迫使我们实现正确的算法,以通过所有的测试,即使我们还没有开始下一个环节的重构。3、重构代码:既然在我们的程序中达到了正确的预期目的,我们应该试图去掉一些重复代码使代码更易维护,更简单,更灵活,也更易于理解。我们可以发现这种改变在运行测试时,并没有影响到程序的行为。修改代码使其易于维护,要求不能修改程序可观察的行为,这个思想并不是全新的理念。然而这里重要的是通过重构,而不是一遍一遍地整理代码。重构必须 是软件开发活动中一个关键的环节,通过合适的工具,并采取系统的方法,可以逐步地改善代码的质量。通过执行贯穿于产品整个生命周期的许多次小的重构,最后 达致最完美的目标,从而使得软件易于维护。倘若

13、必要的反馈要求你的设计(和代码)在产品开发中得到改进,则重构是测试驱动开发中不可缺少的步骤。当然你也可以不执行 TDD 方式,而进行重构以 去除重复代码,使其更简单、灵活、更易于理解。无论你采取什么开发方式,你都需要将重构作为一种常规的活动,以保证你的更改是有效的。重构的力量在于其能够减少因为改变正在工作的代码所带来的危险。好的工具能够帮助你减少潜在的危险,而同等重要的是要采取一系列严谨的步骤和正确的 结构与规则。Martin Fowler 的大作重构:改善既有代码的设计对于重构有非常精彩的描述。他定义了一系列非常有用的重构模式,并提供许多相关的样例指导你怎样进行重 构。目前,Visual S

14、tudio.Net 除了提供查找和替换功能外,对重构没有太多的支持。然而,相信在不远的将来 MS 会提供更多有力的工具,使你能完成更多复杂的工作,例 如符号的重命名,在编译-生成级上更改类名,而不是在你的源文件中作替换操作。你甚至可以期待这样一天的到来当你选中一段代码后,通过 Visual Studio 提供的菜单,直接应用重构模式,然后继续下一步工作。你有充足的信心保证你的程序是更加易于维护的,而不会引入 bugs 或者会改变其可观察的 行为。经验总结迄今为止,你应该明白一条最重要的道理就是 TDD 很简单。事实上,TDD 能帮助你更好地理解任意一门新的语言、新的技术和组件。通过 TDD,你

15、可以 决定将要采取的步伐的跨度。有经验的专家可以采取大的步伐,以避免中间环节。一旦发现开发有误,可以令过程回滚,采取更小的步伐重复前面的过程。关于 TDD 我们需注意下列事项:1、测试使代码文档化(The tests document the code) 。从测试的类 Quad 中可以清晰地看到这点;2、随着测试的进行,我们可以把握进度。通过测试,可以验证每个功能是否正确,如此每个人都可以运行测试来了解过程是否如我们说期望的那样被良好的建立。3、测试让人对代码的修改充满信心。即使你是一个 C#的新手,也可以象专家那样老练的编程,运行所有的测试确保你所做的没有违反既定的规则4、类似于“将长度和宽

16、度以参数的形式传递给面积和周长,而非在构造函数里指定”这样的错误,可以通过重构来修正。5、当你将 TDD 应用到现实世界时,你可以生成许多测试,并通过如 Nunit 的工具来组织它们。使用 Nunit 使测试自动化TDD 可能会生成成千上万个测试。假使项目中的每一个人都在周而复始地重复“写测试,修改代码,重构” ,当然有必要使你的测试工作更加有效。如 Nunit 这样的测试框架就是设计用来帮助你提高效率的利器。它允许你象在 Visual Studio 中建立项目的方式,将你的测试用例装载到 NUnit 中,以合理地安排各自的项目。你可以将所有测试用例以层次结构显示出来,以单用例或测试包 (一组测试用例)的方式运行测试,观察执行后的结果是成功(显示绿色进度条)还是失败(显示红色进度条) ,同时还将显示每次失败的详细信息。另外,NUnit 还提供了一些特殊的方法,使你能够在测试包开始和完成时执行初始化(initialize)和清除(clean up)被不同的测试用例所共享的“测试套件(test fixtures) (例如:长文件,数据库连接,公共链

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 生活休闲 > 科普知识

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号