张恂敏捷 OO 先进软件工程顾问、教练-中式太极敏捷：UDD over TDD

在线 12 人登录 0 人

中式太极敏捷：UDD over TDD

[阅读:52945]

BasicHistory

dearChloe at itpub: 项目管理的一个案例，听听大家的意见

dearChloe 分享的这个案例非常好，在国内还是非常典型的。首先，感谢你的实话实说，提供了这么好的一个案例，我也实话实说。

如果你无法让这个项目的状况变得更好，你退出这个项目是对的。

从软件工程专业的角度看，这个项目失败的概率非常高，可谓又一个 death march 项目，而且正好可以作为敏捷过程的反面教材。从你的介绍中，我看到的全都是些不利因素、障碍或者风险，我没看到能使它成功（高质按时交付）的有利因素。

所以你提的这些问题非常好，也是我想问的：

领导为什么要指派一个技术和业务都不熟悉，并且缺乏项目管理经验的人做项目经理？领导为什么要指派给他的成员都是其他项目的项目经理，并且都是强势的？领导为什么要指派我这种很久已经不写代码的人去写代码？

我觉得你们公司的问题是比较严重的（希望不是积重难返），这看上去更像是一个人浮于事的官僚机构，而不是一个有竞争力、效率至上的当代软件研发机构，当然更不是学习型组织了。所有人（包括领导、项目经理、“强势”的技术人员在内）都不知道当代软件工程已经取得了哪些进展，历史上有哪些经验教训，你们还在用农耕时代的思维和方法开发当代软件、管理当代项目。只缘身在此山中吧。

造成这些现象的原因可能有很多（后面我还会分析），我觉得最大的问题首先在于领导的管理能力和意识没有与时俱进，其次是落后的公司/组织管理制度，以及存在严重缺陷的开发过程规范。

我大体同意你说的，“项目经理是无辜的”。

首先说一下这个项目成员。不算其他边边角角的人员，项目组主要有4个人。这4个人里，有三个都是很强势的人（我一直是项目经理，另一个也是，还做些架构设计；还有一个应届生，虽说他是应届生，但他是很强势的，因为一方面他毕业的院校比较好，另一方面他在学校里也很优秀）。最不强势的人就是项目经理了。为什么项目经理会这样呢？因为他对业务和技术都不懂，而且他自己还很清楚这点，所以他平时就什么都不敢说也不敢管（不过我觉得他也缺乏带项目的经验）。并且，我们3个人都不是全职做这个项目。这个项目涉及的技术我们都没有人用过。

接下来说一下工作安排。由于我是项目开始后加入，所以需求分析我没有参加。然后详细设计，大家讨论，然后每个人分一块来写，项目经理收齐后合并成一份文档，交给领导审批。开发时，再打乱分下来一人开发一个模块。由于，我们部门今年内增加了很多规章制度，要求文档要齐全，格式要标准，并且要经过技术委员会审批。因此当这一切做完，已经到年中了。

然后架构师开始搭开发框架（一边摸索一边搭）。我们开始开发。开发时碰到一些问题：1）对使用的新技术我们都不熟；2）详细设计文档不够详细（文档其实就是为了应付领导），需要不断地询问；3）项目经理不统一项目开发标准和管理项目事项。4）每个人都有其他事情不断地打断开发。

（张恂 1313 字 0 回复 E2009-7-27 11:54:46 LID:35 Hit:102）

(2) Jann Thomas 谈阴阳与软件项目管理

Yin Yang & Project Management

by Jann P. Thomas, 2009-1-7 (ScrumAlliance)

用中国传统文化的阴阳哲学重新诠释了《敏捷宣言》的四条价值观，很好的文章。

4 laws of yin-yang:
- Yin and Yang are opposing.
- Yin and Yang are mutually rooted.
- Yin and Yang mutually transform.
- Yin and Yang mutually wax and wane.

困惑的问题：
Will the developers now have free reign to do whatever they want to do?
Who will be in control?
What is the job of the manager on an agile development team?
How can I move from command and control to cooperation?

Jann 从敏捷项目管理/敏捷项目经理的角度，利用阴阳理论诠释了 4 条敏捷价值观（balanced principles）

Individuals and interactions over processes and tools

A process? Yes. Agile is not anti-process ... the agile project manager must create a process for bringing in new, unplanned work.

To be an agile project manager is to be introspective. A good agile project manager should review and question all of the organization’s existing and developing processes.

敏捷方法和过程本身是科学、严格和规范的（disciplined），事实求是、因地制宜、灵活应变是敏捷的本质特征。

Working software over comprehensive documentation

just enough 是关键。

On agile teams, requirements are developed only when they are ready to be used (just in time), which often results in a smaller set of architectural diagrams, use cases, and functional specifications.

Customer collaboration over contract negotiation

All software projects have some type of contract, whether implied or explicit.

往往造成麻烦的是那些 implied/implicit 的契约/约定。

Negotiating with the customer or product owner on scope is a key component of agile project management.

在 scope 的权衡、决策上，product owner 往往具有更大的主导权。

Responding to change over following a plan

Jann 举了 home building 的例子。的确，软件工程与房屋建造、装修装饰工程有很多相似之处，也是我经常喜欢举的例子。

小结

Jann 说得很好：

Just as yin cannot exist without yang, the elements that agile practitioners value (working software, collaboration, change, and interactions) do not exist without their corresponding yang (documentation, contracts, plans, and process).

懂得了阴阳，就懂得了辩证法，这是东西方共有的智慧。

敏捷和传统并非水与火，彼此对立、不相容的关系，它们是互补的。敏捷和传统的精华结合，才是最好。

（张恂 2270 字 0 回复 E2009-5-23 18:54:13 LID:34 Hit:137）

(3) TDD 能提升质量在意料之中，那么效率呢？

InfoQ 新闻（中文）：

Empirical Studies Show Test Driven Development Improves Quality

TDD 的测试部分其实是某种形式的回归测试（regression test）。与传统回归测试不同的是，TDD 测试频度更高，周期更短。然而，回归测试不是什么新概念，恐怕 25 年以前就有了，属于传统软件工程的精华。回归测试也是 TDD 中最有价值的部分。TDD 测试更频繁，更全面，当然能尽早发现错误，减少错误，获得更稳定的软件，从而提高软件质量，这本在意料之中。作者们用实际案例、定量数据的分析证明了我们的推理，正是这篇研究报告的价值所在。

质量和效率往往是一对矛盾。常识是，获得高质量的软件往往需要耗费更多的时间和精力。

Kent Beck 在他的作品中多次提到，TDD 是一种区别于 model-driven, architecture-driven 的方法。那么，在这份研究报告中，IBM 和微软的项目难道用的是 XP 过程，他们有没有用基于 design model、architecture 的过程方法？这是一个疑问。

案例的情况：

1 个来自 IBM，3 个来自微软。

每个案例研究都对比了开发同一个产品的两个团队，他们使用同样的开发语言和技术，处于同一级别的管理之下，唯一不同之处在于：一个团队使用TDD，另一个不用。

IBM 案例中的团队在开发设备驱动程序，微软的团队在开发 Windows、MSN和Visual Studio的相关应用。

这里没有提到他们采用的开发过程，是否采用了 XP，或者采用了基于模型、架构的开发？

在这篇报告中，提到了 TDD 的两种工作流：minute-to-minute workflow 和 task-level workflow。

分钟级别工作流：

- 编写一些新的小单元测试用例
- 运行测试，看着它们失败
- 编写实现代码以满足测试
- 重新运行单元测试用例，确保它们通过

显然，这些案例项目的 TDD 是单元测试驱动。

任务级别工作流：

- 将新的实现代码和单元测试集成到现有的代码库中
- 重新运行所有的测试用例，确保新的代码不会导致任何测试失败
- 重构实现代码和测试代码
- 重新运行所有的测试用例，确保重构后的代码不会导致任何测试失败

这实际上是重构、回归测试的结合。

实验结果是：

缺陷密度通过 KLOC 缺陷数目来衡量。

相较于不使用 TDD 的项目，这四个产品在发布前的缺陷密度降低了40%到90%。

从团队管理层的主观报告看来，在开发的初始阶段，使用 TDD 的团队要多花 15% 到 35% 的时间；不过团队都同意一点：这个时间被减少的产品维护时间抵消掉了。

我的观点和问题是：

1、这项研究是否说明 TDD 可以用在非 XP 的过程之下？

2、案例中的 IBM、微软项目团队都是非常成熟的软件工程团队，Windows、MSN 和 Visual Studio 也都是非常成熟的产品架构。

如果 TDD 用在国内的典型项目上，增加的开发时间很可能要更多，大概在 50% 甚至 1 倍以上（我个人的估计）。

我曾经在 Kent Beck 和 Martin Fowler 的作品中看到，采用 TDD 代码之后，单元测试代码常常和实现代码的规模差不多，有 2 万行的实现代码，差不多也有 2 万行的（单元）测试代码。

编写高质量的单元测试，也是需要时间的。我估计国内的客户、开发商在做项目计划的时候，大多都没有把这个时间考虑在内，或低估了设计、编写测试、执行测试所需要的时间。

3、采用 TDD，在带来质量提升的同时，有可能降低开发效率，延长交付时间。当然，如果质量回报大于效率损失，那么就值得尝试 TDD。

4、TDD 是可行的，而且可以提高开发质量，这些都没有问题，那么是否还有比 TDD 效率更高、风险更小、更加灵活、更符合大众习惯的开发方式？

我相信是有的。

其他研究

Maria Siniaalto 在 2006 年发布的一篇文章，得出结论：

复审并总结了其他 13 项有关 TDD 的研究，包括在纯商业、半商业和学院背景中进行的研究。

* TDD 看来可以提升软件质量，特别是在纯商业背景中。

* 对于半商业背景或学院环境中的研究来说，结论不是那么明显，可这些研究没有提到任何软件质量的降低。

* TDD 给工作效率带来的效果不是十分明显，而且结果会根据研究的环境发生变化。

* 有证据证明：TDD 不一定会降低开发人员的工作效率，或是增加项目的交付时间。某些情况下，TDD 会带来显著的工作效率提升；同时，在提到的13个案例研究中，只有两个案例指出工作效率降低了，不过这两个案例同时指明质量的提升。

（张恂 2305 字 0 回复 E2009-3-4 15:35:43 LID:33 Hit:148）

/ 概要

咏软件工程

张恂（2009-8-21 作于上海浦东）

万物生逻辑，

千思问玄机；

是非演乾坤，

阴阳汇太极。

软件本太极，阴阳演乾坤。本书主要试图回答以下三个基本（核心）问题，对应地全书也分为三个部分。

第一部分什么是敏捷？

敏捷有西式和中式之分。

很多人以为敏捷就是 Scrum 和 XP，这当然是错误的。Scrum 是当前在国外最流行的敏捷方法。如果 Scrum 能够解决中国软件研发组织的所有问题，那么我们都去参加 Scrum 认证好了，把 Scrum 顾问请来就 ok 了。问题其实没有这么简单。

阴阳太极思想是中国人数千年来的智慧，一种古典、朴素的辩证法。IT 项目管理、系统集成、软件开发、产品研发和软件工程中，处处都离不开科学的辩证思维。我从西式敏捷的价值观以及大量的国外软件工程专家（如 Barry Boehm、Alistair Cockburn、Craig Larman、3 Amigos、Martin Fowler 等等）的文献著作中读出了辩证思想或思维。在国内，人们其实常常会自觉或不自觉地运用辩证思维、方法来解决日常工作中的问题（因为你是中国人），但我同时也发现国内外的 IT|软件专家和达人们都很少明确地指出或提到他们在软件工程中运用的就是辩证法，这是一个奇怪的现象。

中式敏捷可以有很多种，比如张式、陈式、杨式等等。太极敏捷是一种重要的中式敏捷方法，唯物辩证法（dialects）和矛盾论是核心。

第二部分为什么要敏捷？

传统软件工程有很多弊端，敏捷过程和方法是对传统软件工程的继承与发展。大量研究案例和数据已证明敏捷方法能够有效地提高开发效率，提高系统质量，提高客户满意度和员工满意度 ... 敏捷改进能带来这么多好处，过去 5 年来世界上许多先进、领导企业已经作出了示范，使得人们不得不考虑、重视敏捷改进的价值。

我们认为，当代 IT、软件研发组织，无论是 ISO 9001 组织，还是 CMM/CMMI、ITIL 等等各类获得各级证书的组织，都有必要学习、了解敏捷软件工程的管理、技术与方法，在一定程度上借鉴敏捷的做法，实施敏捷变革和改进。

第三部分如何敏捷？

太极敏捷基于辩证思想，吸收、整合了中、西方的敏捷价值观、原则和实践做法，提倡 UDD（User-goal Driven Development，用户目标驱动的开发），学习、借鉴了 Scrum、XP、AgileUP、FDD 等著名敏捷方法的长处，但与它们也有着明显的不同。

本页字数：1369

<添加新主题> <所有评论> 共 22 个主题 35 条评论

(1) 案例讨论：国内典型的 death march 项目

（张恂 1313 字 0 回复 E2009-7-27 11:54:46 LID:35 Hit:102）

(2) Jann Thomas 谈阴阳与软件项目管理

Individuals and interactions over processes and tools

A process? Yes. Agile is not anti-process ... the agile project manager must create a process for bringing in new, unplanned work.

To be an agile project manager is to be introspective. A good agile project manager should review and question all of the organization’s existing and developing processes.

敏捷方法和过程本身是科学、严格和规范的（disciplined），事实求是、因地制宜、灵活应变是敏捷的本质特征。

Working software over comprehensive documentation

just enough 是关键。

Customer collaboration over contract negotiation

All software projects have some type of contract, whether implied or explicit.

往往造成麻烦的是那些 implied/implicit 的契约/约定。

Negotiating with the customer or product owner on scope is a key component of agile project management.

在 scope 的权衡、决策上，product owner 往往具有更大的主导权。

Responding to change over following a plan

Jann 举了 home building 的例子。的确，软件工程与房屋建造、装修装饰工程有很多相似之处，也是我经常喜欢举的例子。

小结

Jann 说得很好：

（张恂 2270 字 0 回复 E2009-5-23 18:54:13 LID:34 Hit:137）

(3) TDD 能提升质量在意料之中，那么效率呢？

- 编写一些新的小单元测试用例
- 运行测试，看着它们失败
- 编写实现代码以满足测试
- 重新运行单元测试用例，确保它们通过

显然，这些案例项目的 TDD 是单元测试驱动。

任务级别工作流：

这实际上是重构、回归测试的结合。

实验结果是：

其他研究

Maria Siniaalto 在 2006 年发布的一篇文章，得出结论：

（张恂 2305 字 0 回复 E2009-3-4 15:35:43 LID:33 Hit:148）

(4) Joel 与 Uncle Bob 的论战：关于 TDD 和敏捷设计

InfoQ 新闻（中文）：

Spolsky vs Uncle Bob

Joel 的观点和中式太极敏捷 UDD 的观点很相近。

关于 TDD

支持 Joel 的观点：

对测试驱动开发有一些争论 …… 应该给所有东西都写单元测试吗，诸如此类的东西 …… 敏捷编程总的观点就是不需要就别做，需要时再引入。我觉得很多时候对所有东西写自动化测试并不能对你有所帮助。

UDD：我们并不需要给所有的代码写单元测试。对于整体应用系统（非框架 API）的开发，很多单元的测试可以通过其他办法间接地做到。

Joel基本上有两个异议，第一个是你把时间花在什么上面了：

我觉得即使团队的单元测试覆盖率达到100%，依然会有一些问题。他们可能花费了相当多的时间编写单元测试，然而质量未必能得到相应的提高。

UDD 观点：

单元测试不如系统功能测试更重要，很多单元测试没必要写。我们应该把时间和精力放在更重要的事情上，比如系统功能测试的驱动。

Joel的第二个异议是测试套件非常脆弱：

我发现单元测试真正的问题在于，随着代码改进，你想修改的内容可能会破坏一定比例的单元测试。有时你修改了代码，不知何故，有10%的单元测试失败了。因为你修改了某些设计...你移动了一个菜单，现在所有依赖菜单的东西仍然存在...而菜单移到了别处。所以这些测试都失败了。你必须能够重写这些测试，以反应代码新的实现。

实际情况，不一定非常脆弱。但在项目开发的早中期，单元测试代码和需求、架构一样不稳定，是有可能的。

这两个异议我基本上都同意。

改良的 TDD

Bob 大叔的回答也是不错的：

我不认为TDD很神圣。我认为它是一个值得遵守的规则。我不会事先编写所有的测试。有一小部分测试在编码后再写只会更方便。甚至有一些代码我根本不会写测试，因为不值得写。但是这些都是例外情况。大多数代码我会先写测试。（不，Joel，这没有浪费我的时间。）

前半部分，我很赞同，TDD 不应该成为神圣的教条。Bob 提出的做法其实是一种改良过的 TDD，放宽了原先 TDD 对开发步骤顺序的严格限制。可见，我们（至少在 Bob 所说的例外情况下）并不需要针对所有实现代码，都必须先写测试代码。一个问题是，如果你不是每次都先写测试代码，后写实现代码，怎么叫 test driven 呢？

Uncle Bob 说，大多数情况下，他会先写测试。具体他没说，是那种类型的测试，估计是单元测试。和 Uncle Bob 不同的是，一般我肯定不会首先去写单元测试，除非有绝对的必要，比方这些单元都很重要，而且它们的外部接口、使用方式和依赖关系已经相对稳定了，需要对外发布这些单元等等。

尤其在开发阶段的早中期，在需求和架构都还不稳定的时候，我更不会首先把精力放在写单元测试上。我会尽量根据功能需求（use case）的基本流、扩展流以及架构的重要性等因素来设计测试，即便要做更小粒度的单元测试，也会首先考虑对一组、一群对象联合进行粒度更大一些的测试。我觉得这种方式效率可能会更高。

UDD 认为需求、架构是软件开发的主要矛盾，每个单元相对于整体和全局来说是次要矛盾，当然这是一对辩证关系。所以，由于存在软件开发哲学观点的差异，TDD 更像是 bottom up 的开发，先保证每个单元积木块的正确，再保证整体、全局的正确；UDD 则更像是 top down（architecure-driven）的开发，先保证整体、全局的稳定和正确，再来完善局部细节。在实践中，其实这两者都是可行的。架构重要？还是单元重要？答案是在运动、变化的。

由于任何带有边界的“系统”（包括类、单元在内）都存在 use case，所以 UDD 的单元测试，也借鉴了 use case/scenario 的设计方法。

针对我所了解的国内的情况，UDD 认为：TDD 对开发步骤顺序的刚性规定（“必须”先写单元测试代码，后写实现代码）在实践中是没有必要的，而且很多时候没有必要从单元测试开始写起。另外，大多数代码都应该努力配上自动系统功能测试，以减少人工测试的麻烦。系统测试的完备性比单元测试的完备性更重要。

关于 TDD 测试的难点：

Bob解释了创建测试套件的重要性，这些测试套件不能像Jeol经历中的那样脆弱，不要一点修改就破坏10%的测试，Bob还介绍了怎样做到这一点，比如通过逻辑和呈现层的分离、在界面显示内容之下正确地测试。Jeff提出Unix社区通常是这么做的，首先写一个命令行程序，然后在其上封装一个UI来驱动它。

如何保证测试套件的稳定性？

Uncle Bob 这个版本的 TDD 听上去更为合理。

关于 SOLID 原则

其他一些不错的观点：

Atwood：规则、准则和原则是从实践中提炼出来的宝藏，值得研究和尊重。但是它们决不能替代对你工作的认真思考。

播客的最后，Jeff、Joel和Bob再次谈到了遵守建议的风险，以及编程社区的技术水平，他们一致认为太多的开发者根本不关心自己在做什么。总之，他们都认为多动脑筋是很有必要的，但感觉他们对开发软件的方式尚未有一致意见。他们三人都承认对变化做出响应很重要，但是要想做到响应变化，需要对设计和测试投入多少是他们分歧的核心，也是整个行业普遍存在的分歧。变化是永恒的，我们如何处理变化却差别甚大。

（张恂 2556 字 0 回复 E2009-2-24 16:15:07 LID:32 Hit:174）

(5) 软件设计的艺术：把握前构与重构的平衡

Prefactoring 与 Refactoring 是两个反义词，两种意义上相对的软件设计活动（和技术）。

由于软件开发的哲学观有所不同，太极敏捷与强调设计以重构为主的 XP 等敏捷方法，在看待前构与重构的关系上，也有许多不同。

以下列举太极敏捷的一些主要观点、结论和对客观事实的分析。

前构

* 软件设计中不可能没有前构活动。

* 敏捷方法反对的是过度的预先设计，不是反对预先设计（前构）。

过度的预先设计，明显会产生很多浪费，你做的设计可能完全没用上。想得太多不好，想得太少不好。软件设计为什么这么难？难就难在如何掌握这个度，微妙的平衡。

* 前构应该包括设计的各种预案，对各种将来可能发生的需求变化的估计和应对准备方案。

* 理想情况下，每位软件设计人员都希望自己的代码和设计能够一步到位，改动越少越好。但事实上，变化是绝对的，没有人是神仙，能够预知未来，掌控一切，所以不可避免地会出现软件设计需要重构的情况。另一方面，软件需要重构的必然性，并不意味着我们应该放弃提高前构能力。

* 程序员的经验越丰富，他的预见能力、前构能力就越强。

初级程序员、经验少的可以只望前看一两步，而软件架构师、设计师的设计应该有更有预见性（和前瞻性），应该在有限的时间内多往前看几步，比方10 步、20 步等。

* 那种走一步、看一步的软件设计，是短视的，效率很低，应该避免，也没有必要。大胆的前构与大胆的重构一样，值得鼓励。

重构

* 软件设计中不可能没有重构活动。

* 重构是一种软件设计的变换，把软件从旧的设计（结构和状态），转变到新的设计（结构和状态），在提高软件质量的同时，保持已实现的需求功能不变。

* “重构”是对上一次设计的重构，对下一次设计的前构。所以，前构与重构其实是统一的，是软件设计中两个连续的活动，同一事物的两面。

* 每次重构都形成一次时间和精力上的浪费，是开发商的内部损耗，因为旧的设计被放弃了，取而代之的是新的设计。两次设计，以及重构的过程，都有一定的开销。

* 有工具支持完成的自动重构，开销可能很小。手工进行的重构，开销较大。

* 重构不可能永远进行下去，必须在项目结束前的某个时刻停止。新的重构只有安排在下次发布或项目中。

* 在实际的项目中，通常重构的次数越少越好。如果客户愿意为你的重构买单，则可以取消这个限制。

* 忽视前构，过度依赖重构，与过度预先设计一样，应该避免。

前构与重构的平衡

* 是否要对将来可能出现的需求变化作出预先设计，取决于我们预估事实发生的可能性（几率）和预估的风险成本。

如果发生几率很大，估计失败的风险成本，以及事后重构的成本都很大，那么就应该大胆前构，提前作好准备。

如果发生几率较小，估计失败的风险成本较小，事后重构的成本也较小，那么就不必提前实现编码，可以静观其变，等到事情发生了，再应对。

复杂的估计，还要考虑如果估计错误，可能导致的风险成本。

这种决策思维，其实和下围棋、象棋，打桥牌差不多。

（张恂 1358 字 0 回复 E2009-2-11 22:45:46 LID:31 Hit:121）

(6) 重构的误区（张恂 934 字 0 回复 E2008-12-5 9:39:10 LID:30 Hit:80）

(7) 善用代码覆盖率（张恂 646 字 0 回复 E2008-11-23 11:47:26 LID:29 Hit:73）

(8) IEEE Software 2007 TDD 特刊（张恂 973 字 0 回复 E2008-8-2 11:49:05 LID:28 Hit:432）

(9) Hakan Erdogmus：TDD 的误解与实施（张恂 536 字 0 回复 E2008-8-2 11:43:29 LID:27 Hit:403）

(10) 系统测试 vs 单元测试

关于 TDD 或单元测试驱动究竟意味着什么，网络上国外专家已经讨论很久了，而且辩论有越来越热的趋势。

我仔细研究了正反方的观点，发现两方说的都有道理，只是双方的立足点、观察角度或 context 不同罢了。

什么时候单元测试非常重要?

我想，在开发框架、平台、可重用库 API 的时候。

比方 .NET Framework 或 Spring Framework 等等，过去 10 年来已经涌现了无数的框架。由于这些框架面向了无数的开发者，每一个公开类、接口（如 String 等等），不起眼的角落都可能被用到，这时单元测试就显得特别重要。很难想象，没有高强度、高覆盖率的大规模单元测试，像 .NET Framework 这样的主流框架如何才能交付使用？

针对可重用框架，单元测试之所以重要的原因是，因为单元正是它们的主要使用/重用单位。

在这种情况下，bottom-up 的 TDD 是比较适合的。

而应用/系统开发则是另外一种情况。

你有 20,000 个完备的单元测试，却可能对验证整个系统（单元的组合）的质量毫无帮助，因为部分能够工作，并不代表由部分结合起来的整体也能工作。20,000 个单元测试，与 20,000 个系统测试，哪一个更有说服力？

而且 20,000 个系统测试通过，则间接意味着至少大量的单元测试也已经通过了。反之，则不然。

所以，对于应用系统开发者来说，关注针对系统整体的功能测试，集成测试，远比单元测试更重要。这也正是 UDD 的着力点之一。

什么时候单元（测试）和系统（测试）会重合？

开发框架的时候。这时，在待开发的单元之外，并没有一个特定的系统，或者说有无数个可能的框架应用系统，所有可重用的单元都是暴露在外的，而每一个单元（类、接口、构件等）都可能被独立使用，这个单元就可以被看作一个待开发的“系统”（仅含有一个公开单元的系统），这时单元测试与系统测试就重合了。

（张恂 837 字 0 回复 E2008-3-7 15:37:58 LID:26 Hit:219）

2007.12.15	简化重构（新增）
2007.6.20	优化重构、慎用重构（新增） UDD over TDD 重新组织，添加了不少内容，尤其在 TDD 的缺陷及其与 UDD 的比较方面
2007.2.9	第三章面向对象设计之道浅论阴阳太极与 UML 建模（新增）
2007.1.4	UDD vs TDD ZX-UDD 开发流程（新增示意图、流程说明和比较）有缺陷的传统开发流程（更新，重画示意图）
2006.11.23	Money 案例用例驱动测试和重构（更新代码，完成账户下单支证券余额的计算）
2006.11.20	Money 案例根据用例需求导出的 UDD 任务表（更新）用例驱动实现（更新代码）用例驱动设计（新增代码）用例驱动测试（新增代码）
2006.11.18	Kent 的 Money 任务表（新增）关于本书的 n 个问题（新增）我为什么要写这本书（更新）

中式太极敏捷：UDD over TDD

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

小结

其他研究

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

小结

其他研究

关于 TDD

改良的 TDD

关于 SOLID 原则

前构

重构

前构与重构的平衡

相关链接