许多现代 Web 服务器代码都会与上游服务进行交互，这些服务会返回 JSON 数据，对 JSON 数据进行少量处理，然后使用流行的单页应用程序框架将其发送到富客户端网页。与使用此类系统的人员交谈时，我听到他们对操作这些 JSON 文档需要做多少工作感到非常沮丧。通过封装加载策略的组合，可以避免很多此类沮丧情绪。

现在，在许多编程环境中，通常将数据结构表示为列表和哈希映射的组合。现在，大多数主要语言都提供这些数据结构的标准版本，以及丰富的操作，特别是集合管道，用于操作它们。这些数据结构非常灵活，允许我们以易于处理和操作的方式表示大多数形式的层次结构。

当我开始我的写作生涯时，我开始为技术杂志撰写文章。现在，当我写文章长度的文章时，它们都是为网络写的。纸质杂志仍然存在，但它们是少数，可能会灭绝。然而，尽管纸质杂志正在萎缩，但纸质杂志的许多假设仍然对作家和出版商产生影响。这在我最近与一些致力于我想在我的网站上发表的文章的人的谈话中尤为突出。

当一个组织采用敏捷思维模式时，企业架构不会消失，但企业架构师的角色会发生变化。企业架构师不再做出选择，而是帮助其他人做出正确的选择，然后传播这些信息。企业架构师仍然需要形成愿景，但随后需要在团队之间架起桥梁，以建立学习型社区。这些将允许团队探索新方法并相互学习，并将企业架构师作为增长的合作伙伴。

我们的大多数软件逻辑都是用我们的编程语言编写的，这些语言为我们提供了编写和演进此类逻辑的最佳环境。但在某些情况下，将该逻辑移动到我们的命令式代码可以解释的数据结构中是很有用的——我称之为自适应模型。在这里，我将展示一些 JavaScript 中的产品选择逻辑，并展示如何将其重构为以 JSON 编码的简单生产规则系统。此 JSON 数据允许我们在使用不同编程语言的设备之间共享此选择逻辑，并在不更新这些设备上的代码的情况下更新此逻辑。

远程工作与集中工作之间没有简单的二分法，相反，团队的分布模式有多种，每种模式都有不同的权衡和适合它们的有效技术。虽然不可能确定结论性证据，但我认为大多数团队在集中工作的方式下效率更高。但是，您可以通过使用分布式工作模式来建立更高效的团队，因为它可以让您接触到更广泛的人才库。

随着程序规模的扩大，将其拆分为模块非常重要，这样您就不需要了解所有内容即可进行小的修改。这些模块通常可以由不同的团队提供并动态组合。在这篇重构文章中，我使用表示层-领域层-数据层对一个小程序进行了拆分。然后，我重构了这些模块之间的依赖关系，以引入服务定位器和依赖注入模式。这些模式适用于不同的语言，但看起来不同，因此我将用 Java 和无类 JavaScript 风格展示这些重构。

必需接口是由交互的客户端定义的接口，它指定了供应商组件需要做什么才能在该交互中使用。

自从我进入我们这个行业以来，将软件开发从费力地编写代码转变为通过简单地组装组件来构建强大的系统的想法一直是一个目标。这是一个有时可以看到但从未真正实现的目标——尽管许多技术都悬挂着工业重用的胡萝卜。

对信息丰富的程序进行模块化的最常见方法之一是将其分为三个广泛的层：表示层（UI）、领域逻辑（又称业务逻辑）和数据访问。因此，您经常会看到 Web 应用程序分为了解如何处理 HTTP 请求和呈现 HTML 的 Web 层、包含验证和计算的业务逻辑层，以及整理如何管理数据库或远程服务中的持久数据的数据库访问层。

Andrew Koenig 在 JOOP 的一篇文章中首次创造了“反模式”一词，遗憾的是这篇文章在互联网上找不到。基本思想（就我记忆而言）是，反模式在您开始时似乎是个好主意，但会让您陷入困境。从那时起，这个词经常被用来表示任何坏主意，但我认为最初的重点更有用。

对齐图是组织信息辐射器，有助于可视化正在进行的工作与业务成果的一致性。这项工作可能是常规功能添加或技术工作，例如重新架构或偿还技术债务或改进构建和部署管道。团队成员使用对齐图来了解他们日常工作旨在改进哪些业务成果。业务和 IT 负责人使用它们来了解正在进行的工作与其关心的业务成果之间的关系。

循环是处理集合的经典方法，但随着编程语言中对一流函数的更多采用，集合管道成为一种有吸引力的替代方法。在本文中，我将通过一系列小示例来研究将循环重构为集合管道。

敏捷软件开发打破了需求分析、测试和开发之间的一些孤岛。部署、运营和维护是其他活动，它们与软件开发过程的其余部分也存在类似的分离。DevOps 运动旨在消除这些孤岛，并鼓励开发和运营之间的协作。

许多开发团队发现微服务架构风格是优于单体架构的方法。但其他团队发现它们是降低生产力的负担。与任何架构风格一样，微服务也会带来成本和收益。要做出明智的选择，您必须了解这些并将其应用于您的特定环境。

集合管道是一种编程模式，您可以在其中将某些计算组织为一系列操作，这些操作通过将一个操作的输出作为集合并将其馈送到下一个操作来组成。（常见操作是过滤、映射和缩减。）这种模式在函数式编程中很常见，在具有 lambda 的面向对象语言中也很常见。本文通过几个如何形成管道的示例来描述该模式，既向不熟悉该模式的人介绍该模式，也帮助人们理解核心概念，以便他们可以更轻松地将想法从一种语言应用到另一种语言。

神秘博士是一部长篇电视剧，但您不必花费太多时间就可以开始欣赏它。挑选优秀的独立剧集很容易。

Tor 如何工作以及如何使用它的摘要。它还涵盖了 Tor 浏览器捆绑包、隐藏服务、Tails，并介绍了围绕 Tor 的一些争议。

在过去的几个月里，我反复听到，获得成功的微服务架构的唯一方法是首先从单体开始。用 Simon Brown 的话说：如果你不能构建一个结构良好的单体，你凭什么认为你可以构建一组结构良好的微服务？最近——而且像往常一样，非常有说服力——对这一论点的阐述来自本网站上的 Martin Fowler。由于我有机会对他早期的草稿发表评论，所以我有一些时间来思考这个问题。我确实思考了，特别是因为我通常发现自己同意他的观点，而且一些我通常同意其观点的人似乎也同意他的观点。

我坚信，从单体开始通常是完全错误的做法。

当我听到有关团队使用微服务架构的故事时，我注意到一个常见的模式。

1. 几乎所有成功的微服务故事都是从一个变得过大的单体开始的，然后被分解了
2. 在我听说过的所有从头开始构建为微服务系统的案例中，几乎所有案例最终都陷入了严重的麻烦。

这种模式导致我的许多同事认为，即使你确定你的应用程序足够大，值得使用微服务，也不应该从微服务开始一个新项目。。

Yagni 最初是一个缩写，代表“你不会需要它”。这是 极限编程 中的一句口号，在敏捷软件团队中经常被普遍使用。它指的是，我们认为软件将来可能需要的一些功能不应该现在就构建，因为“你不会需要它”。

微服务架构风格 是过去一年中的热门话题。在最近的 O'Reilly 软件架构大会 上，似乎每个会议都在谈论微服务。足以让每个人的过度炒作探测器亮起并闪烁。其后果之一是，我们看到团队过于急于拥抱微服务，却没有意识到微服务本身就引入了复杂性。这增加了项目的成本和风险溢价 - 这往往会使项目陷入严重的麻烦。

肯特·贝克在 20 世纪 90 年代后期开发 极限编程 时，提出了他的四条简单设计规则。我这样表达它们。

当我编写处理外部服务的代码时，我发现将访问代码分离到单独的对象中很有价值。在这里，我将展示如何将一些凝结的代码重构为这种分离的常见模式。

数据湖是近十年来出现的一个术语，用于描述 大数据 领域中数据分析管道的重要组成部分。其理念是为组织中任何可能需要分析的原始数据提供一个单一的存储库。通常人们使用 Hadoop 来处理湖中的数据，但这个概念比 Hadoop 更广泛。

运营 martinfowler.com 网站是我在 Thoughtworks 工作的重要组成部分。传统上，它的访问量比我们的主网站多，但随着我们主网站的改进，这种情况将会有所改变。我的网站是我们作为支柱 2 工作的一部分来影响行业的工具。

与任何新的架构术语一样，很难对微服务是什么给出明确的定义，因此本次演讲首先要解决这个问题，其基础是我和 James 共同撰写的一篇文章，该文章引发了人们对微服务的兴趣。然后，我将微服务与 SOA 进行比较，将这种架构与更单一的架构进行比较，并概述了在部署微服务应用程序之前必须做好的重要事情。

我经常参与到关于刻意增加人群多样性的讨论中。软件中最常见的例子是增加女性的比例。例如，在招聘和会议演讲者名单中，我们会讨论试图将女性的比例提高到高于平常的水平。反对推动更大程度多元化的一种常见论点是，这会降低标准，引发人们对多元化但平庸群体的担忧。

一个简单的例子，说明了如何通过首先重构代码以简化更改来更轻松地进行更改。