第1章 引言

本章内容

■ 设计软件时的重要权衡

■ 选择单元测试或集成测试的结果

■ 不存在“一招鲜，吃遍天”的代码与架构设计模式

无论是设计应用程序，还是应用程序接口（application program interface，API），抑或是系统架构，我们都需要做各种各样的决策。这些决策会影响程序的可维护性、性能、可扩展性，产生无数潜在的后果。选定某个技术方向，另一个技术方向的发展就会受到一定限制，这种事在软件开发中屡见不鲜。系统存续的时间越长，修正之前的决策、改变系统的设计越困难。本书会用大量篇幅讨论设计软件时，如何在两个或者多个技术方案间进行选择。无论你的选择结果是什么，选择技术方案时清晰地了解其“优缺利弊”，做到“了然于胸”很重要。

通常情况下，开发团队需要结合项目背景、上市时间、服务等级协定（service level agreement，SLA）以及其他相关因素综合考量，才能做出一个艰难的决策。我们将毫无保留地向你展示设计软件系统时所做的那些权衡与取舍，并将其与其他可选方案进行比较。希望读完本书，你会开始关注每天都在做的那些设计决策。关注这些，尤其是熟稔每种决策的优缺点，可以帮助你做出清晰的选择。

本书先着重讨论每位软件工程师在做API设计和编码时都应考虑的基础设计决策，接着讨论软件设计中更宏观的部分——架构及各组件间的数据流，还将讨论采用分布式系统架构时需注意的取舍。

接下来介绍进行取舍分析时所采用的方法。首先，我们着重讨论每位软件工程师都得做的判断：如何在单元测试、集成测试、端到端测试，抑或是其他类型的测试之间实现平衡。在实际项目中，通常开发团队要在有限的开发周期内发布软件以创造价值。因此，我们要决定在哪类测试中投入更多的时间，是单元测试、集成测试、端到端测试，还是其他类型的测试，我们会逐一分析每种测试类型的利与弊。

然后介绍久经考验的单例模式，剖析为什么上下文差异会导致该设计模式的可用性发生变化。我们会结合单线程和多线程上下文实例进行阐述。最后，我们会从宏观角度分析采用微服务与单例模式的利与弊。

注意，描述软件架构时，简单地用纯微服务（only micro-service）或者纯单例模式（only monolithic）都是不确切的。我们经常在实际软件项目中看到混合模式的架构：一些功能以服务的方式实现，另一些功能则以单体系统的方式实现。譬如某个遗留系统，它可能整体而言是单体形态，少部分功能是由微服务架构实现的。此外，一个全新项目初始时只是一个应用，如果花费极高的代价将其微服务化，往往是得不偿失的。即便你采用混合架构，也需要根据项目实际情况，选择性地运用。

对于每一章内容的介绍，我们均采用这样的方式：首先介绍某个特定背景下的难题是如何解决的，接着分析其他备选的解决方案，最后补充介绍当时做决策的上下文及最终的选择。我们会分析每种解决方案在特定上下文中的利与弊。接下来的各章会围绕设计软件系统时的决策做更深入的探讨。