任何重要的软件开发工作都需要进行几项不同的活动：分析、用户体验设计、开发、测试等。以活动为导向的团队围绕着这些活动进行组织，因此您拥有专门的用户体验设计、开发、测试等团队。以活动为导向承诺了许多好处，但软件开发通常最好由 以结果为导向 的团队完成。

当通过多个引用访问同一个内存位置时，就会发生别名。这通常是件好事，但它经常以一种意想不到的方式发生，从而导致令人困惑的错误。

这是一种已经存在很长时间的反模式，但目前似乎又特别流行起来。我和 Eric Evans 聊过这个，我们都注意到它们似乎越来越受欢迎。作为真正 领域模型 的拥护者，这不是一件好事。

Andrew Koenig 在 JOOP 的一篇文章中首次提出了“反模式”一词，遗憾的是这篇文章在互联网上已经找不到了。其基本思想（就我记忆所及）是，反模式是指一开始看起来是个好主意，但最终却会让你陷入困境的东西。从那以后，这个词经常被用来表示任何坏主意，但我认为最初的重点更有用。

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

双峰IT是一种错误的观念，认为应该将软件系统分为这两个不同的类别进行管理和控制。

• 前台系统（交互系统）应针对快速功能开发进行优化。这些交互系统需要对不断变化的客户需求和商业机会做出快速反应。缺陷应该被容忍，因为这是快速开发周期的必要成本。
• 后台系统（记录系统）应针对可靠性进行优化。作为记录系统，重要的是不要出现损害企业的缺陷。因此，您需要放慢变更速度。

调用父类方法是面向对象框架中不时出现的一种小问题（或者说反模式，如果您愿意这样称呼它的话）。它的症状很容易发现。您正在继承一个超类，以便插入到某个框架中。文档上说“要完成您自己的工作，只需继承 process 方法即可。但是，重要的是要记住，在开始编写方法时，要先调用超类的方法”。例如，可能是这样的。

现代应用服务器经常宣传的功能之一是它们在集群中提供故障转移。集群提高了应用程序的可靠性，如果一台服务器出现故障，您还有其他服务器可以为客户提供服务。故障转移可以进一步提高可靠性，如果一台服务器在交互过程中出现故障，集群可以将该交互转移到另一台服务器。

然而，这可能是一个问题。

每当将两三个值收集在一起时 - 就将它们变成一个 $%#$%^ 对象。

-- 我自己（用声音说出来会更有趣）

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

（这是对您的词典的补充。）

不可测试（形容词）：不可测试的软件。

尽管很容易习以为常，但很明显，软件开发领域在多样性方面存在一些严重的问题。我的意思是，与普通人群相比，我们在人员比例上存在一些显著差异。最明显的差异之一是女性比例低，这在世界各地都是如此（尽管在中国不那么明显）。在美国，我大部分时间都在那里度过，非裔美国人的缺乏也很明显。关于造成这种不平衡的原因以及如何解决这个问题，已经有很多文章了。但在这里，我想集中讨论一个更根本的问题——这重要吗？

前几天，我正在编写我书中的一些示例代码。我做了一些修改，让一切都正常工作，运行了测试，并将其提交到我的个人存储库中。然后，我转到另一个区域，做了一些修改——结果在之前的区域中，一些意外的测试失败了。现在，运行自动化测试的部分意义在于发现意外的错误，但这本书的代码区域是完全独立的。这很奇怪。

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

最近我听到不少项目都遇到过一个问题。情况是这样的

• 他们想使用敏捷流程，并选择了Scrum
• 他们采用了Scrum实践，甚至可能还采用了Scrum原则
• 一段时间后，由于代码库一团糟，进度缓慢

标志参数是一种函数参数，它根据其值告诉函数执行不同的操作。假设我们要预订一场音乐会。有两种预订方式：普通和高级。要在这里使用标志参数，我们最终会得到一个方法声明，如下所示

有时，当我处理某些数据时，这些数据的精度超出了我的预期。有人可能会认为这是一件好事，毕竟精度越高越好。但隐藏的精度会导致一些微妙的错误。

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

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

我最近一直在研究 JavaScript，令我震惊的一件事是，人们习惯于对 getter 和 setter 使用相同的函数名。因此，如果您想在 jQuery 中获取横幅的高度，可以使用 $("#banner").height()，而如果想更改高度，可以使用 $("#banner").height(100)。

我对这种约定很熟悉，因为它在 Smalltalk 中使用。您可以使用 banner height 获取值，并使用 banner height: 100 更改值。知道这是一种 Smalltalk 约定就足以让我喜欢它，因为我对这种语言有着遥远而持久的热爱。但即使是最好的东西也有缺陷，我无法掩饰我对这种编码风格的厌恶。

IT 部门中的一个常见问题是，是通过构建定制软件还是购买软件包来提供功能。从我开始编程以来，关于如何做出选择的争论就一直在激烈进行。我在这方面的基本立场是基于 实用性与战略性二分法。归根结底，这意味着，如果您所支持的业务流程是您竞争优势的一部分，那么您应该构建定制软件；如果不是，那么您应该购买软件包，并调整您的业务流程以适应软件包的工作方式。

尽管我的观点显然很出色，但似乎没有多少公司这样做。他们经常忽略这种二分法，这是一个问题。但我在这里想关注的是他们在购买软件包时经常遇到的陷阱。

软件的好处之一是人们似乎想要它，而且想要得很快。组织通常会要求团队加快软件的生产速度，而且组织会不时地以一种真正体现其承诺的方式来提供帮助——花钱为团队增加人手。

那些听过我和我的同事谈论特性分支的人都知道我们不是这种模式的狂热粉丝。我们反对的一个重要原因是，我们观察到分支很容易，但合并却很难。我们不时听到的一种说法是，现代版本控制工具使合并变得足够容易，因此特性分支是值得的。

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

幻灯片文档是幻灯片和文档的混合体。其理念是，您可以使用同一套幻灯片，既可以在演示过程中作为幻灯片，也可以在演示结束后作为讲义供人们阅读。问题是，这两种需求对幻灯片的要求截然不同，因此您无法同时满足它们。结果是，幻灯片文档通常无法同时满足这两种需求。

保持生产服务器的正常运行可能是一件棘手的事情。您必须确保操作系统和任何其他依赖软件都已正确修补，以保持最新状态。托管应用程序需要定期升级。经常需要更改配置以调整环境，使其高效运行并与其他系统正确通信。这需要混合使用命令行调用、在 GUI 屏幕之间跳转和编辑文本文件。

结果就是一个独特的雪花——这对滑雪胜地来说是好事，但对数据中心来说却是坏事。

故事测试是面向业务的测试，用于描述和验证作为用户故事一部分交付的软件。当一个故事被详细说明时，团队会创建几个故事测试，作为该故事的验收标准。故事测试可以组合成软件的回归测试套件，并提供从需求（用户故事）到测试以及（通过执行）到系统行为的可追溯性。故事测试通常是广栈测试。

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

随着我的职业生涯转向全职写作，我经常担心自己与日常软件开发的现实脱节。我见过其他知名人士与现实失去联系，我担心自己也会遭遇同样的命运。我对这一点最大的抵制力量是 Thoughtworks，它就像一剂定期的现实剂量，让我脚踏实地。

Thoughtworks 也是来自该领域的思想来源，我喜欢写我的同事们发现和开发的有用的东西。通常，这些都是有帮助的想法，我希望我的一些读者能够使用。我今天的话题不是一个令人愉快的话题。这是一个问题，而且我们没有答案。

在软件领域，“瀑布式”通常用于描述一种软件流程风格，它与迭代或敏捷风格的理念形成对比。与软件中许多众所周知的术语一样，它的含义定义不清，起源也不明——但我发现它的基本主题是将一项大型工作分解成基于活动的阶段。