本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 改善开发周期
<a name="improve-dev-cycle"></a>

云端开发软件给软件工程师带来了新的挑战，因为在开发计算机上本地复制运行时环境非常困难。验证软件的一种直接方法是将其部署到云端并在那里进行测试。但是，这种方法涉及漫长的反馈周期，尤其是当软件架构包含多个无服务器部署时。改善这种反馈周期可以缩短开发功能的时间，从而大大缩短上市时间。

## 在云端进行测试
<a name="testing-cloud"></a>

直接在云端进行测试是确保您的架构组件（例如 Amazon API Gateway 中的网关、 AWS Lambda 函数、Amazon DynamoDB 表 AWS Identity and Access Management 和 (IAM) 权限）正确配置的唯一方法。它也可能是测试组件集成的唯一可靠方法。尽管有些 AWS 服务（例如 D [ynam](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html) oDB）可以在本地部署，但大多数服务无法在本地设置中复制。同时，第三方工具（例如 [Moto](http://docs.getmoto.org/en/latest/)）和用于测试目的[LocalStack](https://localstack.cloud/)的模拟 AWS 服务可能无法准确反映真实的服务API合同，或者功能的数量可能有限。

但是，企业软件中最复杂的部分在于业务逻辑，而不是云架构。架构的更改频率低于域名，因为域必须适应新的业务需求。因此，在云端测试业务逻辑成为一个紧张的过程，包括更改代码、启动部署、等待环境准备就绪并验证更改。如果部署只需 5 分钟，则在业务逻辑中进行和测试 10 项更改将需要一个小时或更长时间。如果业务逻辑更复杂，则测试可能需要等待几天的时间才能完成部署。如果您的团队中有多个功能和工程师，那么延长的期限很快就会引起业务的注意。

## 本地测试
<a name="testing-local"></a>

六角形架构可以帮助开发人员专注于领域，而不是基础架构的技术细节。这种方法使用本地测试（您选择的开发框架中的单元测试工具）来满足域逻辑要求。您不必花时间解决技术集成问题或将软件部署到云端来测试业务逻辑。你可以在本地运行单元测试，并将反馈回路从几分钟缩短到几秒钟。如果部署需要 5 分钟，但单元测试在 5 秒钟内完成，那么检测错误所需的时间就会大大缩短。本指南后面的[首先测试业务逻辑](improve-software-quality.md#logic)部分将更详细地介绍这种方法。

## 开发的并行化
<a name="parallel"></a>

六角形架构方法使开发团队能够并行完成开发工作。开发人员可以单独设计和实现服务的不同组件。这种并行化是通过隔离每个组件以及每个组件之间定义的接口来实现的。

## 产品上市时间
<a name="time-to-market"></a>

如前所述，本地单元测试可以改善开发反馈周期，缩短新产品或功能的上市时间，尤其是当这些产品或功能包含复杂的业务逻辑时。此外，通过单元测试增加代码覆盖率可以显著降低更新或重构代码库时引入回归错误的风险。单元测试覆盖率还使您能够持续重构代码库以使其井井有条，从而加快新工程师的入职流程。这一点将在本[质量源于设计](improve-software-quality.md)节中进一步讨论。最后，如果业务逻辑经过良好的隔离和测试，它可以使开发人员快速适应不断变化的功能和非功能需求。本[适应变化](adapt-to-change.md)节将对此进行进一步解释。