重构第一版和第二版之间变更的简要概述

将单体应用拆分成更小的服务时，最困难的部分实际上是拆分单体应用数据库中的数据。要提取数据密集型服务，最好遵循一系列步骤，始终保留数据的单个写入副本。这些步骤首先在现有单体应用中进行逻辑分离：将服务行为拆分为单独的模块，然后将数据拆分为单独的表。这些元素可以分别移入新的自治服务。

从表面上看，敏捷软件开发的世界一片光明，因为它现在已经成为主流。但现实令人担忧，因为所做的大部分工作都是伪敏捷，无视敏捷的价值观和原则。我们应该关注的三个主要挑战是：打击敏捷工业体系及其将流程强加于团队的习惯，提高技术卓越性的重要性，以及围绕产品（而不是项目）组织我们的团队。尽管存在问题，但社区最大的优势在于其学习和适应能力，能够解决我们最初的宣言作者无法想象的问题。

一篇关于我如何使用 AppleScript 和 Ruby 编写导出脚本的简短文章

我正在完成我的《重构》一书的新版本。以下是有关我工作的详细信息和定期备忘录。

无服务器架构是结合了第三方“后端即服务”(BaaS) 服务的应用程序设计，和/或包含在“函数即服务”(FaaS) 平台上的托管、临时容器中运行的自定义代码。通过使用这些想法以及单页应用程序等相关想法，此类架构消除了对传统始终在线服务器组件的大部分需求。无服务器架构可以从显着降低的运营成本、复杂性和工程交付周期中受益，但代价是增加了对供应商依赖以及相对不成熟的支持服务的依赖。

随着单体系统变得过于庞大而难以处理，许多企业都被吸引将其分解为微服务架构风格。这是一段值得尝试的旅程，但并不容易。我们已经了解到，要做好这一点，我们需要从一个简单的服务开始，然后提取出基于对业务至关重要且经常发生变化的垂直功能的服务。这些服务最初应该很大，并且最好不要依赖于剩余的单体应用。我们应该确保迁移的每个步骤都代表了对整体架构的原子改进。

敏捷方法已成为主流，但这种流行并非没有问题。组织领导者抱怨说，他们没有获得预期的收益。本文介绍了一种流畅度模型，可以帮助您充分利用敏捷理念。流畅度通过四个不同的区域发展，每个区域都有其自身的优势、所需的熟练程度和关键指标。

如今，每个人都在构建“平台”以加速大规模交付数字产品。但是，是什么造就了一个有效的数字平台？一些组织在尝试在其现有共享服务的基础上进行构建时步履蹒跚，因为他们没有首先解决其组织结构和运营模式问题。

“测试金字塔”是一个比喻，它告诉我们将软件测试分组到不同粒度的桶中。它还给出了我们应该在每个组中进行多少次测试的想法。尽管测试金字塔的概念已经存在了一段时间，但团队仍然难以将其正确地付诸实践。本文回顾了测试金字塔的原始概念，并展示了如何将其付诸实践。它展示了您应该在金字塔的不同级别寻找哪些类型的测试，并给出了如何实现这些测试的实际示例。

软件项目是资助和组织软件开发的一种流行方式。他们将工作组织成临时的、仅构建的团队，并通过商业案例中预测的特定收益获得资金。产品模式则使用持久的、构思-构建-运行的团队来处理持续的业务问题。产品模式允许团队快速调整方向，缩短端到端周期时间，并允许通过使用短周期迭代来验证实际收益，同时保持其软件的架构完整性以保持其长期有效性。

集成测试确定独立开发的软件单元在相互连接时是否正常工作。这个词甚至被软件行业中普遍存在的标准所模糊，因此我一直谨慎地在写作中使用它。特别是，许多人认为集成测试的范围必然很广，而实际上可以通过更窄的范围更有效地完成集成测试。