如果你阅读过许多标准文档，除了需要大量的咖啡之外，你还需要注意一些词语的含义重载。

角色接口是通过观察供应商和消费者之间的特定交互来定义的。供应商组件通常会实现多个角色接口，每个接口对应一种交互模式。这与头接口形成对比，在头接口中，供应商只有一个接口。

头接口是一种显式接口，它模仿类的隐式公共接口。本质上，您需要获取类的所有公共方法，并在接口中声明它们。然后，您可以为该类提供另一种实现。这与角色接口相反 - 我将在那里讨论更多细节以及优缺点。

现在JRuby越来越成熟，有几个人正在考虑最终做些什么来改进构建脚本的世界，用rake替换ant。

你如何提高软件开发人员的生产力？

在过去几年中，人们对Web 2.0进行了很多讨论，包括其概念及其作为新词的价值。我在这方面的参与有限，我阅读并听取了Tim O'Reilly关于这个主题的演讲，并参加了他组织的一个研讨会。然而，外面有很多困惑，所以我想是时候让我做一次徒劳的尝试来减少这种困惑了。(由于我在很大程度上是在解释Tim的意思，如果我们有任何分歧，你应该相信他。)

我习惯于创造新词来描述我在软件开发中看到的东西。这是该领域作家们的共同习惯，因为软件开发仍然缺乏很多有用的术语。构建术语的一个问题是，术语很容易失去其含义，在一个语义扩散的过程中 - 使用另一个可能添加到我们术语中的词。

新词

1：一个新词、用法或表达。
2：精神病患者创造的毫无意义的词。

-- 韦氏词典

如果你读过我写的很多东西，你会很快注意到我是一个强迫性的新词创造者。我总是在寻找新的词语和短语，事实上，这个博客就是围绕着这个习惯设计的。

敏捷方法的一种常见做法，也许是占主导地位的做法，是为正在构建的软件开发一个功能列表(通常称为故事)。这些功能用索引卡、工作队列、燃尽图、积压工作或您选择的任何工具进行跟踪。

通用语言是Eric Evans在领域驱动设计中使用的术语，指的是在开发人员和用户之间建立一种通用的、严谨的语言的实践。这种语言应该基于软件中使用的领域模型 - 因此需要它严谨，因为软件不能很好地处理歧义。

关于结对编程的一些常见误解。

Ruby最受欢迎的功能之一是它对元编程的支持，即那些看起来像改变语言本身的功能 - 引入了像新关键字这样的东西。

对象之母是测试中使用的一种类，用于帮助创建用于测试的示例对象。

内部DSL(通常称为嵌入式DSL)是一种用现有宿主语言编写的领域特定语言。这是许多编程语言社区中一种常见的思维方式 - 特别是Lisp社区。随着DSL成为快速发展的Ruby社区中一种常见的思维方式，它现在正受到越来越多的关注。

如果你关心你所做的事情，你就会关心如何把它做得更好。这包括反思你做事的方式，并尝试新的技术，看看它们是否能让你做得更好。即使其他人推荐新技术，你唯一知道它们是否适合你的方法是自己尝试，看看它们是否能提高你的表现。

面向对象领域中持续时间最长的争论之一是开放继承和设计继承之间的争论。设计继承的原则可能最好地概括为Josh Bloch的话："为继承而设计和记录，否则就禁止它"。使用这种方法，您需要注意决定哪些方法可以继承，并密封其他方法以防止它们被覆盖。

根据敏捷联盟现任董事会的说法，敏捷方法已经"跨越了鸿沟"，我认为这意味着它们正在变得越来越普遍。虽然这有其优势，但也带来了问题。当一种方法论或设计方法变得流行时，我们会看到很多人在使用它或教授它，他们关注的是时尚，而不是真正的细节。这可能会导致以敏捷的名义完成的事情与该运动创始人的原则截然相反。

我之前说过(在本页的早期版本中)，我无法理解一台没有清晰、可审计的纸质记录的投票机怎么会被认为是可接受的投票方式。普林斯顿大学最近的一项研究进一步支持了这一观点，该研究表明，颠覆常见的投票机是多么容易。(通过Glenn Vanderburg)

最近，苹果公司发布了时间机器，它能够让您回到过去，查看您对文件的所有更改，包括查找已删除的文件。对于我们中的一些狂热的技术爱好者来说，这并不是什么新功能。和其他人一样，我把我的整个工作目录都放在版本控制之下，最初是CVS，现在是Subversion，因此我一直能够轻松地查看我对所有工作内容的所有更改。这是一个非常有用的功能，我以前就想知道拥有更多版本控制会是什么样子，也许时间机器就是朝着这个方向迈出的一步。

这与设计继承的态度相反。开放继承的支持者不希望通过密封他们的类或做任何其他事情来阻止人们继承类。

不久前，Jon Udell描述了两种公开演讲模式：

• 脚本化：你几乎把你将要说的内容都写出来，然后要么读出来，要么记住它。
• 幻灯片驱动：你制作详细的幻灯片，并用它们来驱动你所说的话。

我现在的公开演讲大多使用第三种模式 - 即兴演讲。在这种风格中，我一开始只准备了一个粗略的演讲提纲，然后在演讲过程中完成所有其他内容。

当谈到领域特定语言这个话题时，一个常见的难题是，到底什么是DSL，什么不是DSL。问题在于，DSL没有精确的定义，而且在DSL和其他事物之间存在着很大的灰色地带。

我花了很多精力在写模式上。我时不时地会被问到我为什么要这样做，以及是什么造就了一个好的模式。这是一篇关于我如何看待模式的简短文章，并为那些有兴趣自己编写模式的人提供了一些建议。

当有人在寻找是什么造就了一流的企业软件开发人员时，谈话往往会转向对框架和语言的了解，或者可能是理解复杂算法和数据结构的能力。对我来说，程序员或开发团队最重要的特征之一是客户亲和力。这是指开发人员对软件所要解决的业务问题以及生活在该业务领域的人们的兴趣和密切程度。

在过去四年中，Thoughtworks在印度班加罗尔设立了一个实验室，以支持我们在北美和欧洲的软件开发项目。传统的离岸开发方法基于计划驱动的方法，但我们坚定地站在敏捷阵营。在这里，我将讨论我们在进行离岸敏捷开发方面的经验和教训。到目前为止，我们已经发现我们可以让它发挥作用，尽管其好处还有待商榷。(虽然本文最后一次更新是在2006年，但我在2011年访问了我们的离岸工作，发现这些经验教训仍然适用，因此本文不需要进一步的重大修改。)

GUI架构如何演变的历史概述，特别关注不同群体多年来如何看待模型-视图-控制器。从历史的角度来看，这与我的演示模式有关。

在新兴的 Rails 社区中，“企业级”正成为一个贬义词。对许多人来说，Rails 框架以其积极的简洁性，与过于复杂的 “企业级” 框架形成了鲜明对比。

用户界面中模式的叙述性概述。讨论了如何以及为什么要将领域逻辑与表示分离，以及如何分离和同步数据层。

2001 年 2 月，17 位软件专家齐聚犹他州雪鸟城，讨论当时被称为轻量级方法的不断发展的领域。我们决定使用“敏捷”一词来描述这种新型的 敏捷方法。我们还撰写了 敏捷软件开发宣言，阐述了这些敏捷流程的价值观和原则。我是这些自荐的远见者之一，此后遇到了许多关于该小组的起源以及随后敏捷联盟成立的问题。以下是我对这些事件的回忆。

我已经多次谈到 持续集成 的优点。要使这样的环境正常工作，您需要一个持续集成服务器和一个源代码控制系统。为了使项目顺利进行，您还可以使用问题跟踪器来进行错误跟踪等，并使用 Wiki 来帮助捕获各种项目知识。

2001 年在犹他州雪鸟城举行的会议决定使用“敏捷”一词，并开始了“敏捷软件开发宣言”。

与我的大多数主题演讲一样，这是一个 即兴演讲。鉴于会议的主题，这次演讲的主题是 Rails 如何影响软件开发。

在我最近关于 评估 Ruby 的帖子中，我提到一位同事开发了一个具有一些精美数值图表的 Web 应用程序。有人发邮件问我他是怎么做到的。我在最初的博客文章中添加了我的简短回答，ploticus，但这又引出了一个问题，即他是如何将 Ruby 与 ploticus 连接起来的？

最近博客圈的一场争议是由尼古拉斯·卡尔的一篇文章引起的，该文章声称“维基百科之死”（是的，我知道我的回应很慢，但我当时在路上没有时间写作）。他最初的帖子让我觉得很奇怪，他说维基百科正在消亡，因为 0.01% 的文章受到了一种相当温和的保护。这就像说当一个城镇雇用了一名警察时，民主就结束了。

本文讨论了服务提供者和消费者社区发展过程中面临的一些挑战。它描述了当服务提供者更改其契约（尤其是文档架构）的某些部分时出现的一些耦合问题，并确定了两种广为人知的策略——添加架构扩展点和对接收到的消息执行“恰到好处”的验证——以缓解此类问题。这两种策略都有助于保护消费者免受提供者契约更改的影响，但它们都没有让提供者了解其使用方式以及在发展过程中必须维护的义务。本文借鉴了其中一种缓解策略（“恰到好处”的验证策略）的基于断言的语言，描述了“消费者驱动的契约”模式，该模式使提供者能够洞悉其消费者义务，并将服务演进重点放在交付消费者所需的关键业务功能上。

今年年初我出差很多，所以我的写作完全停滞了。几周前我回到家，希望能完成很多写作任务。嗯，我已经完成了一些，但总是有事情让我分心：手术取出事故中留下的钢钉，被 洪水 淹没。但最大的生产力杀手是我自己造成的——买了一台新电脑。

在过去几年里，我们最喜欢的玩具之一是 Squeezebox。这是一个非常简单的设备——大约路由器大小，带有电源、以太网、放大器和无线局域网天线的端口。它的工作是从服务器获取流式传输的 mp3 文件，并通过放大器播放它们。

在我最近的 代码所有权 帖子中，我描述了我对代码所有权问题的看法。我的许多软件开发朋友都是极限编程的拥护者，他们倾向于集体代码所有权。然而，这类实践并非绝对的，应始终根据当地情况进行调整。我的一位同事给我发了一封邮件，其中讲述了以下故事，我认为这很好地说明了什么时候必须改变你的实践，即使你是 XP 的忠实粉丝。（因为他谈论的是他的团队，所以他希望匿名。）

关注新闻的你可能已经注意到，新英格兰遭遇了一场春季大风暴，并发生了严重洪灾。我住在梅尔罗斯，那里正好位于雨区中心，整个周末的降雨量接近 10 英寸。人们说，自 1938 年飓风以来，这里从未发生过这样的事情，尽管与过去几年世界其他一些地方遭受的灾难相比，这只是一件小事。

我遇到过各种代码所有权方案。我将它们分为三大类

如果你正在阅读本文，我假设你已经意识到，关于 Ruby 编程语言，尤其是用于开发 Web 应用程序的 Rails 框架，存在着大量的炒作。有些人认为它是编程的未来，而另一些人则认为它是一种危险的分流。

在过去的一个月左右的时间里，我一直待在我们的英国办公室，与 Thoughtworks 的各位英国同事交流。我本来打算去拜访我们的一些客户项目，但仅仅是与办公室内外的人交流就让我忙得不可开交（这也让我在写书方面毫无进展，但这可以等我回家后再做）。

当他们看到一个 getter 方法时，你可以从他们嘴角左侧的抽搐中认出他们，他们会迅速拔出他们的战斧，并发出一声满意的呐喊，因为另一个 getter 被无情地从一个类中砍了下来，而这个类立即陶醉在男子气概的 Getter 终结者脚下的感激之情中。

使用 setter 初始化，您可以构造一个空对象，然后使用 setter 方法在运行中设置各种属性。（构造函数初始化 的替代方法。）

代码异味是一种表面迹象，通常对应于系统中更深层次的问题。这个词最初是由 Kent Beck 在帮助我编写 重构 一书时创造的。

构造函数初始化是一种方法，您可以在对象的创建方法中传入对象所需的所有协作者。它是 Setter 初始化 的替代方法。

我作为一名作家获得成功的一个副作用是，我成了一位小有名气的极客。这种名气非常小，通常只在极客会议上才会显现出来（尽管我确实遇到过几次在旧金山的餐馆里有人走到我面前）。在它发生之前，我真的没有想太多，只是对名声有一点渴望。现在它发生了，我更加意识到了这一点——总而言之，我讨厌它。

将企业应用程序视为对外部世界事件做出反应的系统，这是长期以来的一种思考方式。这种思维方式在 80 年代下半叶的结构化设计社区中开始流行起来。现在，你可以在“事件驱动架构”的旗帜下听到它。在 2000 年代中期，我开始收集这类系统的一些模式，但此后一直未能将它们变成更充实的东西。尽管它们还很粗糙，但我确实认为它们提供了一些关于事件协作本质的有用想法，引入了“事件溯源”一词，使用并行模型来表示世界的假设状态，以及如何使用协议调度器来组织领域逻辑。

一个模式叙述，着眼于如何将事件用作系统如何运行以及如何与对等方协作的焦点。总结了如何表示事件、如何使用事件在系统之间进行集成以及在系统架构中使用事件溯源。

对会计有用的模式的叙述。包含账户、分录和交易的基本表示，以及对进行会计调整的模式的概述。

Gerard Meszaros 正在 写一本书，以捕捉使用各种 XUnit 框架的模式。他遇到的一个棘手问题是，人们用来在测试中模拟系统部分的 stub、mock、fake、dummy 和其他东西的各种名称。为了解决这个问题，他想出了自己的词汇表，我认为值得进一步推广。

XUnit 是一系列测试框架的家族名称，这些框架在软件开发人员中广为人知。该名称源自 JUnit，这是第一个广为人知的此类框架。

契约式设计 (DbC) 和测试驱动开发 (TDD) 的拥护者之间一直存在着旷日持久的争论，尽管这种争论并不激烈。我现在不打算深入探讨这个问题，但我将传递一个想法，将两者融合在一起，这个想法是我在与 Daniel Jackson 交谈时想到的。

当人们说一个方法不会改变对象的“可观察状态”时，是什么意思？

每当两个或三个值聚集在一起时——就把它们变成一个 $%#$%^ 对象。

-- 我（用语音说更有趣）

这是我最喜欢的重构书籍中提到的 代码异味 之一。当你经常看到相同的几个数据项一起传递时，你就会发现它。例如，start 和 end 就是一个想要成为 范围 的数据块的好例子。通常，数据块是没有人想将其转换为对象的原始值。

Java 和 C# 都共享相同的纯接口类型模型。你可以通过 interface Mailable 声明一个纯接口，然后你可以声明你用 class Customer implements Mailable（在 Java 中）实现它。一个类可以实现任意数量的纯接口。这个模型忽略的一件事是，只要你有一个类，你就有一个隐式接口。