经常阅读我作品的读者可能知道，我非常怀疑使用其他行业的比喻来解释软件开发。特别是，我认为工程比喻对我们的行业造成了损害——因为它鼓励了将设计与构建分离的观念。

当我在我们伦敦办公室闲逛时，这个问题在精益制造的背景下被提了出来，精益制造是一个在敏捷圈子里经常使用的比喻——尤其是Poppendiecks。如果我不喜欢土木工程的比喻推理，那么我会更喜欢精益制造的比喻推理吗？

大多数版本控制系统依赖于使用和理解工件版本之间的变化——通常被称为差异，来自可以在 Unix 中生成它们的命令。好的差异（和合并）算法适用于文本和二进制文件。这些差异的问题在于它们相当愚蠢。它们所做的只是查看两个工件版本并生成一种从一个版本到另一个版本的简单方法。

我们最近进行了年度潜水度假。每次我们这样做时，我们都会面临一个困境——我们是去我们非常喜欢的萨巴，还是尝试一些新的地方？我们对此的答案是去萨巴和一个新的地方，这导致了一个更长的假期，弥补了从冰冻的东北部长途跋涉的辛苦。我们的新地方是多米尼加。

作为一个一直使用版本控制的人，我认为它可以扩展到计算机使用的更多领域。除了软件开发人员之外，很少有计算机用户使用版本控制。然而，正如软件开发人员所知，版本控制是一种很好的协作工作机制，允许多个人在一个软件系统上一起工作。更广泛地使用版本控制会带来什么好处？

Sergey Dmitriev 是JetBrains的领导者之一，JetBrains 为我们提供了 IntelliJ Idea 和 ReSharper 等优秀工具。他最近发表了一篇文章，介绍了他所做的一些探索性开发，称为元编程系统。他将该系统视为更广泛运动的一个例子，他称之为面向语言编程。

我已经参加 OOPSLA 十多年了。它已经成为我与许多朋友聚会并了解他们最近在做什么的地方，并试图了解面向对象社区的发展方向。

我的分布式对象设计第一定律：不要分发你的对象（来自企业应用架构模式）。

清晰的代码是好的，但你应该为了可测试性而牺牲清晰度吗？

敏捷开发的基本原则之一是，需求变化不仅是预期的，而且是受欢迎的。当像 Thoughtworks 这样的外部公司为客户工作时，这构成了一个特殊的挑战。许多客户希望达成固定价格协议，这实际上是固定范围，因为他们看到了固定范围的幻觉。但是固定范围的合同与敏捷开发完全不一致，那么像我们这样的公司该怎么办？

如果你一直在关注我的Thoughtworks 博客同事，你就会知道，我的一个笨蛋机器人似乎烧坏了保险丝，澳大利亚的阳光显然烤焦了这些瑞典模特。

Jon 对数据传输对象感到恼火，但这并不是说 DTO 是一件坏事，就像任何模式一样，它们在某些情况下很有用。模式总是有两部分：怎么做和什么时候做。你不仅需要知道如何实现它们，还需要知道什么时候使用它们，什么时候不要使用它们。

当我听我们的开发团队谈论他们的工作时，一个共同的主题是他们不喜欢静态的东西。通常，我们会看到常见的服务或组件保存在具有静态初始化器的静态变量中。静态变量（在大多数语言中）的一个大问题是，你不能使用多态性用一个实现替换另一个实现。这让我们很头疼，因为我们非常喜欢测试——为了测试好，能够用服务存根替换服务非常重要。

在 Debian 上安装大多数东西都非常简单：apt-get install package-name。遗憾的是，Java 是一个例外，因为它不在基本的 Debian 系统中。我最近在我的 Debian Sid 桌面上下载并安装了 Java 1.5（或 5，或者他们现在怎么称呼它）。简而言之，程序如下。

许多公司喜欢签订固定范围和价格的合同，因为他们认为这降低了他们的风险。这种幻觉认为，他们的财务义务固定在交易价格上。如果他们没有得到满意的软件，那么他们也不需要付出任何代价。

随着人们对动态语言的兴趣日益浓厚，越来越多的人开始接触一种称为 Lambda 的编程概念（也称为闭包、匿名函数或块）。来自 C/C++/Java/C# 语言背景的人没有使用过 Lambda，因此不确定它们是什么。这里有一个简要的解释，那些在具有 Lambda 的语言中进行过大量编程的人不会觉得这很有趣。

Subversion 是一个开源版本控制系统——本质上是 CVS 的继任者。它修复了 CVS 中最大的问题，引入了原子提交以及对文件和目录重命名的支持等功能。我已经使用它几年了，发现它非常可靠。

我最近听到了一些关于为使用极限编程计划方法的多个团队制定标准故事点机制的问题。希望是让几个团队都使用等效的故事点，这样在一个团队中三个故事点的努力与在另一个团队中是相同的。

我认为尝试做到这一点充其量是价值有限的，最坏的情况是危险的。

几个圣诞节前，Cindy 送给我一个麦哲伦 Meridian Gold GPS 设备。因为我比一般的熊更擅长导航，所以我没有把它看作是我真正需要的东西，而是一个可以玩的东西。从那以后，我发现它更像是一个有趣的玩具，而不是我真正经常使用的东西。

这是一个由 Przemyslaw Pokrywka 提出的有趣难题。这本书中的其中一项重构是引入空对象——一项非常有用的重构（在Josh 的新书中也有讨论）。Przemyslaw 的观点是，这种重构可以改变行为。如果你有一个方法返回一个空值，并且你在该空值上调用一个方法，你将得到一个空指针异常。如果你使用一个空对象，你将得到一些默认行为。

如果你为了提高程序的性能而进行更改，这算不算重构？

更改声明顺序（例如 Java 程序中的方法和字段）算不算重构？

重构邮件列表最近有一些关于什么是或不是重构的讨论。与这些讨论一样，总是有争论一根针尖上能容纳多少个天使的危险，但思考边界确实有一些有用的目的。

在我的重构一书中，我给出了重构的几个定义。

如果软件要崩溃，Jim 在本专栏中解释了为什么它应该尽快崩溃。

我经常会遇到一些问题，这些问题都围绕着JUnit测试框架中的一个设计选择——为每个测试方法运行创建一个新对象的决定。足以保证快速写一篇博客文章。（然而，我觉得几乎不得不指出，我写的关于 JUnit 的文章并不意味着我认为其他形式的测试不重要。有许多有用的测试活动，尽管 JUnit 及其同类产品对其中许多活动都很有价值，但它并不是万能的。有关测试的更多博客文章，我建议你阅读Brett Pettichord、Brian Marick和James Bach的博客。你也不能认为我写的关于 xUnit 测试的文章暗示了重构、用例或使用牙线的不重要性。）

Cindy 非常注重木工的工艺。她会注意到我忽略的各种细节。她特别欣赏那些看起来不怎么样，但实际上很难做好的东西。

当你编写一个类时，你主要努力确保该类的特性对该类有意义。但在某些情况下，添加一个特性以允许类符合比它自然应该符合的更丰富的接口是有意义的。

我正在翻阅一些旧笔记，偶然发现了 Rich Garzaniti 给我的一个简单但有用的技巧。

此页面现已弃用，因为我不再认为它是信息的有用来源。有关此主题的更好介绍，请访问面向活动

本页面现已弃用，因为我认为它不再是有用的信息来源。有关此主题的更详细介绍，请访问OutcomeOriented

本页面现已弃用，因为我认为它不再是有用的信息来源。有关此主题的更详细介绍，请访问以业务能力为中心

我在Thoughtworks工作感到很自在的原因有很多，其中很大一部分是因为这里的大多数人都和我有着广泛的共同原则。多年来引起一些争论的一点是我们对自己知识产权的态度——本质上我们是免费提供的。

（鼠标、Belkin KVM 切换器和 Linux 的问题）

这些现在被称为Squeezebox。

人们不时会问起如何让一本书进入我的签名系列。市面上有很多书籍系列，每个系列都有自己的决定接受哪些书籍的方式。以下是我决定接受哪些书籍的方式

大多数人最了解关系数据模型是通过关系数据库和 SQL 语言。通俗地说，我们认为数据库是一组表，每个表中的每一行都包含数据。我们可以通过各种方式操作这些表来进行查询，每个查询都会生成另一个表。与网络数据模型相比，表之间没有显式指针，链接是通过连接表上的公共值建立的（尽管使用代理键意味着您实际上拥有指针。）

如果您学习面向对象设计，您很快就会了解封装数据的重要性。最简单的封装形式是使用访问器（获取和设置方法）或属性——如果您的语言支持的话。（有些甚至在类中执行此操作——自我封装

现场客户是极限编程的实践之一，是白皮书中提到的 12 种实践之一。它指出，客户应该与开发人员一起坐在他们的开放工作区，以便随时回答问题并与开发团队互动。事实上，他们是开发团队的一部分，并且认识到团队的成功既取决于他们，也取决于开发人员。他们不必为了做到这一点而放弃他们的日常工作，但他们必须亲自到场。

这是一个朋友的朋友的故事。我相信这肯定是真的，至少在某些地方是真的。

我使用应用程序数据库一词来指代由单个应用程序控制和访问的数据库（与集成数据库相对）。由于只有一个应用程序访问数据库，因此可以专门定义数据库，以轻松满足该应用程序的需求。这会导致生成更具体的模式，该模式通常比集成数据库的模式更容易理解，而且通常也不那么复杂。

网络数据模型将数据结构化为记录类型，并使用指针链接来实现在一条记录和另一条记录之间导航。因此，要查询网络数据模型，您需要从一条记录开始，并围绕指针引用移动。

几年前，我改变了工作生活中一个重要的方面。在那之前，我尝试只在一台计算机上工作（或者更严格地说，只在一个硬盘驱动器上工作）。我所有的工作文件都保存在我的笔记本电脑硬盘上。如果我使用台式机，我会通过文件共享工具使用这些文件。

用例是一种组织和获取需求的技术。它们最初是由 Ivar Jacobson 在 20 世纪 80 年代末和 90 年代初推广的。

形容词：一种技术、工具或设计理念，显然过于简单可笑，不可能有任何好处，但当你开始使用它时，它所具有的力量却与其简单性不相符。

Knoppix是一个 Linux 发行版，具有一些有趣的特性。

在我看来，《设计模式》是有史以来关于面向对象设计的最佳书籍，也可能是关于任何设计风格的最佳书籍。这本书对软件行业产生了巨大的影响——看看 Java 和 .NET 库就知道了，它们充斥着 GOF 模式。

在经过漫长的等待之后，JetBrains 的人员已经开始了他们的 C# 工具的早期访问计划。遗憾的是，他们忽略了我的命名建议，而是将其命名为ReSharper。我同事的早期反馈非常热情，但仍然希望有更多改进。

C3 是克莱斯勒综合薪酬项目的简称，这是克莱斯勒的一个工资项目，后来因成为极限编程的“诞生地”而闻名。

层次数据模型以层次结构或树结构的形式组织。早期的数据库和编程数据结构通常使用层次模型，但这些模型已经失宠。在数据库领域，关系数据模型占据了主导地位，而对于大多数内存编程来说，网络数据模型占据了主导地位。这是因为层次结构虽然是一种简单的组织工具，但当您拥有更复杂的数据时，它就会崩溃。

最近几个月，我一直在疯狂地安装Debian Linux。在过去的几个月里，我的设置中出现了很多新环境。我买了一台新的台式机，并在上面安装了 Windows XP，一台安装了 MacOS X 的 Powerbook 笔记本电脑，以及一台安装了 Windows XP 的新的工作笔记本电脑。所有这些都需要进行各种各样的工作，即使是我的工作笔记本电脑（预装了 Thoughtworks 配置的 Windows XP）也需要进行一些工作来安装我在工作中使用的各种应用程序。

每个人都有自己的一套重要的设计准则。Scott 专注于接口以及如何设计它们，以便于正确使用和难以错误使用。

资产捕获是开发扼杀者应用程序的一种策略。您可以将许多应用程序视为管理一组关键资产。工资系统负责管理员工，交易系统负责管理交易，租赁系统负责管理租赁。要逐步切换到新系统，您可以先确定要从新系统开始使用的一组资产。通常，最适合开始使用的资产是简单的资产（因为它们可以快速启动）或那些使用旧系统特别难以处理需求的资产。

当 Cindy 和我去澳大利亚时，我们花了一些时间在昆士兰海岸的雨林中。这个地区的自然奇观之一是巨大的扼杀者无花果。它们在树的上枝上播种，并逐渐向下生长，直到扎根于土壤中。多年来，它们长成了奇妙而美丽的形状，同时扼杀了作为它们宿主的树木。

如果您正在使用 XP 风格的计划，您需要从开发人员那里获得快速的共识估算。抛出估算可以让您快速判断开发人员对估算的看法是否相似（以便您可以记下它并继续进行），或者是否存在分歧（当您需要更详细地讨论用户故事时）。

我绘制了很多 UML 图，但我没有使用 CASE 工具。原因是我对UML 草图感兴趣，而不是对所有存储库内容感兴趣。到目前为止，我的常规选择是 Visio。尽管 Visio 附带了 UML 模板，但我没有使用内置的模板——我更喜欢Pavel Hruby的模板。

我发现这是一种可悲的常见架构风格。您的公司购买了一些非常昂贵的基础设施软件。然后，您被告知必须在项目中使用它，即使它不适合该项目并会导致您付出额外的努力。在为此支付了这么多钱之后，您不希望它白白浪费，对吧？

我看到关于敏捷项目的最常见问题之一是，它们如何处理向另一个团队的交接。如果您有一个开发团队离开并将支持工作移交给了一个支持团队，那么当敏捷项目往往比计划驱动的流程生成少得多的文档时，他们如何应对？

集成数据库是一个数据库，它充当多个应用程序的数据存储，从而跨这些应用程序集成数据（与应用程序数据库相对）。

当我谈到数据库以及它们与应用程序的关系时，我发现区分两种数据库风格很有用：应用程序数据库和集成数据库。两者之间的区别在于数据库是否在单个应用程序边界内进行控制和封装。

作为一名软件开发作家和演讲者，我提供了大量关于我们行业的通用建议。无论是像说明装饰命令如何工作那样具体，还是像如何思考您的软件开发态度那样具有哲学意义，我所发出的噪音都是无穷无尽的。此外，我只是众多通用建议提供者中的一员：作家、分析公司、记者，这些建议比任何人都能读到的要多。

这条原则说的是，你今天完成的工作量将与你昨天完成的工作量一样多。在迭代项目中，它表示您应该计划在本次迭代中完成与上次迭代相同的工作量。这个术语来自极限编程社区。

我参加过很多次会议的小组讨论，也自己组织过几次。当我组织小组讨论时，我喜欢使用一种基于英国电视时事讨论节目“Question Time”的特定形式。我已经这样做了几次，并且比传统的专家小组更喜欢这种形式。

处理带单位的数字，例如：12 英尺和 9.99 美元

将一系列值（例如 10 月 22 日至 25 日）视为单个对象。

我时不时会遇到一些人，他们不仅不同意我说的话，而且对我所说的话感到震惊。“像你这样的权威人士说的话，很多人都会盲目地照做”。

对于许多短暂接触极限编程的人来说，XP 似乎要求软件设计的消亡。不仅许多设计活动被嘲笑为“前期大设计”，而且诸如 UML、灵活框架甚至模式之类的设计技术也被淡化或完全忽略。事实上，XP 涉及大量的设计，但它的方式与已建立的软件过程不同。XP 通过允许进化成为可行的设计策略的实践，重振了进化设计的概念。它还提供了新的挑战和技能，因为设计人员需要学习如何进行简单设计、如何使用重构来保持设计的整洁，以及如何以进化风格使用模式。

在 2003 年的 OOPSLA 大会上，Dave Thomas（OTI 的创始人）对模型驱动架构进行了深刻而有力的批判。在本专栏中，他解释了为什么他认为通用的模型驱动方法可能会失败，并指出 UML 和领域特定语言仍然具有价值。

敏捷方法是否应该有一个认证计划？

我已经旅行回来了，为了回报我在电子邮件中收到的所有建议，以下是我对我们三周日本之旅的一些感想。

普通开发人员可以使用敏捷方法吗？

2002 年，我参加了 XP/敏捷宇宙大会的一个研讨会，当时“用实例说明”这个词让我印象深刻，它可以用来描述测试在 XP 中的作用之一。

我写的是关于设计的文章，我认为即使在讨论一些抽象的设计模式时，提供源代码示例也是有用的。当然，这可能会导致人们认为代码示例就是模式，但我认为这种风险与代码提供的精确性相比微不足道。很多时候，我不太确定一个想法，但一个代码示例有助于我澄清它。因此，在我写的关于设计的文章中，我总是尽量提供代码示例。

软件开发中的许多争论都取决于发言者是持 指导性态度 还是 赋能性态度。这些不同的态度会影响对语言、设计、工具、流程等等的选择。

两种 软件开发态度 之一。指导性态度认为，由于大多数开发人员都不太好（据说几乎 50% 的开发人员都低于平均水平），我们需要指导他们做事的方式。这种指导是为了防止他们对正在开发的系统造成损害。通常，这种态度体现在设计和工具中，这些设计和工具会阻止开发人员做某些事情，限制他们可以做的事情，让他们远离复杂领域。

两种 软件开发态度 之一。赋能性态度认为开发人员是负责任的专业人员，因此应该给予他们做任何需要做的事情的自由。遵循这种态度的设计应该使事情易于使用，但应该假设开发人员知道他们在做什么，因此不要试图阻止某些事情被错误地使用。因此，这些工具可能会被误用，但要采取的态度是，用户应该更清楚地知道，如果他们不知道，他们就应该承担一切后果。

模块化编程不仅仅是关于面向接口编程，它还关于在各个模块不知道它们正在与哪些具体模块对话的情况下将模块组装在一起。

我早期最喜欢的书籍之一是 Tsichritzis 和 Lochovsky 合著的关于数据模型的书籍。这本书讨论了思考数据的不同模型，特别是当时讨论最多的三种模型：关系数据模型、层次数据模型 和 网络数据模型。

当我第一次接触 C# 时，我就很喜欢属性的概念。C++/Java 中的 getX 和 setX 约定对我来说总是很傻，写成 obj.X = other.X 要自然得多。提供具有 get 和 set 方法的属性将常见的约定变成了语言自然支持的特性。

有些人认为 模型驱动架构 (MDA) 将是自汇编语言转向第一批高级语言以来软件开发领域的最大转变。另一些人则认为它只不过是“活死人案例工具之夜”。我属于后者，但我认为需要的不仅仅是一句俏皮话。

这是一种非常常见的模式，也很简单，它实际上只是应用于命令的装饰器模式。我见过它在 面向命令的接口 中大量使用。你还会听到它被称为拦截器，以及面向方面编程的一种形式。

当人们谈论 极限编程 时，他们通常关注的是它的自适应计划风格，或者它的演进式设计方法。一个小的但越来越明显的趋势让我特别感兴趣，那就是越来越多的 XP 项目的缺陷率非常低，我指的是每月少于一个生产缺陷。

在 Java 社区中，涌现出大量轻量级容器，它们有助于将来自不同项目的组件组装成一个 cohesive 的应用程序。这些容器的基础是它们执行连接的通用模式，这个概念被称为“控制反转”。在本文中，我将深入探讨这种模式是如何工作的，它有一个更具体的名称叫做“依赖注入”，并将其与服务定位器替代方案进行对比。它们之间的选择不如将配置与使用分离的原则重要。

Bruce Eckel 最近关于 ant 和 make 的 博文 触发了我分享一些关于构建语言的想法。ant 和 make 都指定了构建是如何发生的，它们是描述构建的语言。两者都被广泛使用，并且都很成功。然而，两者都遇到了局限性，在更大的系统中，人们经常会发现使用其他程序生成 ant/make 文件。

以下是我最近发现的一个有趣的对比。两个规模相似（约 10 万行代码）、环境相似（Java 和 .NET）的企业应用程序项目。一个项目可以在一个小时内完成完整的构建和测试，而另一个项目需要 2-3 分钟。

对于许多人来说，敏捷方法最难理解的事情之一就是敏捷的以人为本。那些对敏捷流程感兴趣的人都同意，流程对项目成功的影响是次要的。敏捷宣言 的第一个价值观是，个人和交互比流程和工具更有价值。

XML 已经出现一段时间了，它被大量使用——事实上比它应该被使用的次数还要多。像大多数工具一样，XML 适用于某些事情，而不适用于其他事情。

“重构”曾经只是一个少数人知道的术语，现在却在计算机行业中广为流传。我乐于认为我对此负有一定责任，并希望它能改善一些程序员的生活和一些企业的利润。（重要的一点是，我不是重构之父或发明者——只是一个记录者。）

重构、JUnit 等工具以及极限编程 (XP) 等敏捷方法的日益普及，带来了一种新的设计风格。持续设计是使用重构来持续改进程序设计的过程。在本专栏中，Jim 将讨论他在持续设计方面的经验，特别是那些看起来很棘手的设计问题，如国际化和事务。

从面向对象开发的最初开始，面向对象设计就与迭代和增量开发联系在一起。但正如许多人指出的那样，两者之间没有内在联系。你可以在瀑布模型中进行面向对象，你也可以在没有对象的情况下进行 IID。那么，为什么两者如此紧密地联系在一起呢？