大家好。 期待课程的推出 ，传统上与您分享有用材料的翻译。
软件解决了越来越多的日常任务，同时也变得越来越复杂。 正如马克·安德烈森曾经说过的，它吞噬着世界。
因此，应用程序的开发和交付方式在过去几年中发生了巨大变化。 这些构造规模的变化导致了一系列原则的产生。 事实证明，这些原则有助于团队建设、设计、开发以及向最终用户交付应用程序。
其原则可概括如下： 应用程序应该很小，基于 Web，并且具有以开发人员为中心的架构。 牢记这三个原则，您可以创建强大的端到端应用程序，该应用程序可以快速、安全地交付给最终用户，并且易于扩展和扩展。
每个提出的原则都有许多方面，我们将讨论这些方面，以展示每个原则如何有助于最终目标，即快速交付易于维护和使用的可靠应用程序。 我们将研究与它们的对立面相关的原则，以澄清其含义，例如，“确保你使用 微小原则“。
我们希望本文能够鼓励您使用所提出的原则来构建现代应用程序，这将在不断增长的技术堆栈的背景下提供统一的设计方法。
通过应用这些原则，您会发现自己利用了软件开发的最新趋势，包括 到应用程序的开发和交付、容器的使用（例如， ）和容器编排框架（例如， ）、微服务的使用（包括微服务架构 и 用于微服务应用程序。
什么是现代应用程序？
现代应用？ 现代堆栈？ “现代”到底是什么意思？
大多数开发人员对现代应用程序的组成只有一个大概的了解，因此有必要明确定义这个概念。
现代应用程序支持多个客户端，无论是 React JavaScript 库用户界面、Android 或 iOS 移动应用程序，还是连接到另一个 API 的应用程序。 现代应用程序意味着其提供数据或服务的客户端数量不定。
现代应用程序提供 API 来访问所请求的数据和服务。 API 应该是不可变的和恒定的，而不是专门为特定客户端的特定请求而编写的。 API 可通过 HTTP(S) 访问，并提供对 GUI 或 CLI 中所有可用功能的访问。
数据必须以普遍接受的、可互操作的格式提供，例如 JSON。 API 以干净、有组织的方式公开对象和服务，例如 RESTful API 或 GraphQL 提供了不错的接口。
现代应用程序构建在现代堆栈上，而现代堆栈就是分别支持此类应用程序的堆栈。 该堆栈允许开发人员轻松创建具有 HTTP 接口和清晰的 API 端点的应用程序。 所选方法将使您的应用程序能够轻松接收和发送 JSON 格式的数据。 换句话说，现代堆栈对应于十二因素应用程序的元素 .
这种类型的堆栈的流行版本基于 , , , , и 。 微服务架构 代表了用上述每种语言实现的现代堆栈的示例。
请注意，我们并不提倡完全的微服务方法。 你们中的许多人正在使用需要发展的整体应用程序，而其他人则正在处理正在扩展和发展成为微服务应用程序的 SOA 应用程序。 还有一些人正在转向无服务器应用程序，有些人正在实施上述应用程序的组合。 本文概述的原则适用于这些系统中的每一个，只需进行一些小的修改。
原则
现在我们对什么是现代应用程序和现代堆栈有了共同的理解，是时候深入研究架构和开发原则了，这将有助于您开发、实现和维护现代应用程序。
其中一个原则听起来像是“制作小型应用程序”，我们就这样称呼它吧 微小原则。 有非常复杂的应用程序由许多移动部件组成。 反过来，用小型、分立的组件构建应用程序可以更轻松地作为一个整体进行设计、维护和使用。 （请注意，我们说的是“简化”而不是“变得简单”）。
第二个原则是，我们可以通过帮助开发人员专注于正在开发的功能来提高开发人员的生产力，同时使他们在实施过程中摆脱基础设施和 CI/CD 的担忧。 所以，简而言之，我们的方法 专注于开发人员.
最后，应用程序的所有内容都必须连接到网络。 在过去的 20 年里，随着网络变得更快、应用程序更加复杂，我们在网络化未来方面取得了长足进步。 正如我们已经看到的，现代应用程序必须由许多不同的客户端通过网络使用。 将网络思维应用于架构具有显着的好处 微小原则 以及该方法的概念， 面向开发者.
如果您在设计和实现应用程序时牢记这些原则，您将在产品的开发和交付中拥有不可否认的优势。
让我们更详细地看看这三个原则。
微小原则
人脑很难同时感知大量信息。 在心理学中，认知负荷一词是指将信息保留在记忆中所需的脑力劳动总量。 减少开发人员的认知负担是当务之急，因为这使他们能够专注于解决问题，而不是将整个应用程序的当前复杂模型和正在开发的功能保留在他们的头脑中。
应用程序因以下原因而分解：
- 减少开发人员的认知负担；
- 加速和简化测试；
- 快速交付应用程序中的更改。
有多种方法可以减少开发人员的认知负担，这就是小型原则发挥作用的地方。
因此，以下是减少认知负荷的三种方法：
- 减少他们在开发新功能时必须考虑的时间范围——时间范围越短，认知负荷越低。
- 减少执行一次性工作的代码量 - 更少的代码 - 更少的负载。
- 简化对应用程序进行增量更改的过程。
缩短开发时间
让我们回到方法论的时代 waterfall 是开发过程的标准，开发或更新应用程序的时间框架为六个月到两年是常见的做法。 通常，工程师会首先阅读相关文档，例如产品需求（PRD）、系统参考文档（SRD）、架构蓝图，然后开始将所有这些内容组合成一个认知模型，并根据该模型进行编码。 随着需求以及架构的变化，必须付出很大的努力来通知整个团队有关认知模型的更新。 这种方法在最坏的情况下可能会导致工作瘫痪。
应用程序开发过程中最大的变化是敏捷方法的引入。 该方法论的主要特点之一 agile 是一个迭代开发。 反过来，这会减少工程师的认知负担。 不需要开发团队在一个长周期内实现应用程序， agile 方法使您能够专注于可以快速测试和部署的少量代码，同时还可以接收反馈。 该应用程序的认知负荷已从六个月转变为两年，并在两周内添加大量规格或更改功能，旨在使人们对大型应用程序的理解更加模糊。
将重点从大型应用程序转移到可以在两周冲刺内完成的特定小功能，并且在下一个冲刺之前只考虑一个功能，这是一个重大变化。 这使我们能够提高开发效率，同时减少不断波动的认知负荷。
在方法论上 agile 最终的应用预计将是原始概念的略微修改版本，因此开发的终点必然是模糊的。 只有每次具体冲刺的结果才能清晰、准确。
小代码库
减少认知负荷的下一步是减少代码库。 通常，现代应用程序非常庞大 - 一个强大的企业应用程序可能包含数千个文件和数十万行代码。 根据文件的组织方式，代码和文件之间的链接和依赖关系可能是显而易见的，反之亦然。 即使调试代码执行本身也可能存在问题，具体取决于所使用的库以及调试工具区分库/包/模块和自定义代码的程度。
构建应用程序代码的工作心理模型可能需要花费大量时间，并且再次给开发人员带来巨大的认知负担。 对于整体代码库来说尤其如此，其中存在大量代码，其功能组件之间的交互没有明确定义，并且由于不尊重功能边界，关注对象的分离通常是模糊的。
减少工程师认知负担的有效方法之一是转向微服务架构。 在微服务方法中，每个服务都专注于一组功能； 而服务的含义通常是明确且易于理解的。 服务的边界也很清晰 - 请记住，与服务的通信是通过 API 完成的，因此一个服务生成的数据可以轻松传递到另一个服务。
与其他服务的交互通常仅限于少数用户服务和少数使用简单干净的 API 调用（例如使用 REST）的提供者服务。 这意味着工程师的认知负担大大减轻。 最大的挑战仍然是理解服务交互模型以及事务（例如事务）如何在多个服务之间发生。 因此，微服务的使用通过减少代码量、定义清晰的服务边界以及提供对用户和提供者之间关系的理解来减少认知负荷。
小的增量变化
原则的最后一个要素 渺小 是变革管理。 对于开发人员来说，查看代码库（甚至可能是他们自己的旧代码）并说：“这太糟糕了，我们需要全部重写”是一种特别的诱惑。 有时这是正确的决定，有时则不是。 它给开发团队带来了全局模型变更的负担，进而导致巨大的认知负担。 工程师最好专注于他们在冲刺期间可以做出的更改，以便他们能够及时（尽管是渐进的）推出必要的功能。 最终产品应类似于预先计划的产品，但进行一些修改和测试以满足客户的需求。
当重写大部分代码时，有时无法快速交付更改，因为其他系统依赖项会发挥作用。 为了控制更改流程，您可以使用功能隐藏。 原则上，这意味着该功能已在生产中，但无法使用环境变量设置 (env-var) 或某些其他配置机制来使用。 如果代码已通过所有质量控制流程，那么它最终可能会以潜在状态投入生产。 但是，此策略仅在最终启用该功能时才有效。 否则，它只会使代码变得混乱，并增加开发人员为了提高工作效率而必须处理的认知负担。 变更管理和增量变更本身有助于将开发人员的认知负荷保持在可承受的水平。
即使只是简单地引入附加功能，工程师也必须克服许多困难。 就管理层而言，明智的做法是减少团队不必要的负担，以便团队能够专注于关键的功能要素。 您可以做三件事来帮助您的开发团队：
- 使用方法论
agile限制团队必须专注于关键功能的时间范围。 - 将您的应用程序实现为多个微服务。 这将限制可以实现的功能数量，并强化保持认知负荷的边界。
- 更喜欢增量更改，而不是大而笨拙的更改小块代码。 使用功能隐藏来实现更改，即使它们在添加后不会立即可见。
如果您在工作中应用小规模原则，您的团队将会更加快乐，能够更好地专注于实现必要的功能，并且更有可能更快地推出质变。 但这并不意味着工作不能变得更加复杂，有时，相反，引入新功能需要修改多个服务，而这个过程可能比单体架构中的类似过程更加困难。 无论如何，采用小型方法的好处是值得的。
第一部分结束。
很快我们将发布翻译的第二部分，现在我们正在等待您的评论，并邀请您 ，将于今天 20.00 点举行。
来源： habr.com