本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 改善開發週期
<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 服務 （例如 [DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoDBLocal.html)) 可以部署在本機，但大多數服務無法在本機設定中複寫。同時，用於測試目的之模擬 AWS 服務的第三方工具，例如 [Moto](http://docs.getmoto.org/en/latest/) 和 [LocalStack](https://localstack.cloud/)，可能無法準確反映實際服務 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) 本節會進一步說明。