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

# 平衡自主權與對齊
<a name="balance-autonomy-alignment"></a>

微型前端架構強烈偏向團隊自主權。不過，請務必區分可支援彈性和各種方法來解決問題的領域，以及需要標準化才能達成一致性的領域。資深領導者和架構師必須儘早識別這些領域，並排定投資優先順序，以平衡微型前端的安全性、效能、卓越營運和可靠性。尋找此平衡包含下列項目：微型前端建立、測試、發行和記錄、監控和提醒。

## 建立微型前端
<a name="create"></a>

理想情況下，所有團隊都強烈保持一致，以最大限度地提高最終使用者效能的優勢。實際上，這可能很困難，而且可能需要更多的努力。我們建議從一些書面準則開始，多個團隊可以透過開放和透明的爭論做出貢獻。然後，團隊可以逐步採用 Cookiecutter 軟體模式，它支援建立工具，提供統一的方式來堆疊專案。

使用此方法，您可以根據意見和限制條件進行烘焙。缺點是，這些工具需要大量投資才能建立和維護，並確保在不影響開發人員生產力的情況下快速解決封鎖程式。

## 微型前端的End-to-end測試
<a name="testing"></a>

單位測試可以留給擁有者。我們建議您儘早實作策略，以跨測試在唯一 Shell 上執行的微型前端。策略包括在生產版本前後測試應用程式的功能。我們建議為技術和非技術人員開發程序和文件，以手動測試關鍵功能。

請務必確保變更不會降低功能或非功能客戶體驗。理想的策略是逐漸投資於自動化測試，包括主要功能和架構特性，例如安全性和效能。

## 釋放微型前端
<a name="release"></a>

每個團隊可能都有自己的方法來部署自己的程式碼、在意見中烘焙，以及自己的基礎設施。維護這類系統的複雜性成本通常令人生死。相反地，我們建議您提早投資 ，以實作可由共用工具強制執行的共用策略。

使用所選 CI/CD 平台開發範本。然後，團隊可以使用預先核准的範本和共用基礎設施來發佈生產變更。您可以提早開始投資此開發工作，因為這些系統在初始測試和整合期間之後很少需要重大更新。

## 日誌記錄和監控
<a name="logging"></a>

每個團隊可以有不同的業務和系統指標，他們想要追蹤這些指標以進行操作或分析。Cookiecutter 軟體模式也可以在此處套用。事件的交付可以抽象化，並以多個微型前端可以使用的程式庫的形式提供。為了平衡彈性並提供自主性，請開發工具來記錄自訂指標並建立自訂儀表板或報告。報告可促進與產品擁有者的緊密合作，並減少終端客戶意見回饋迴圈。

透過標準化交付，多個團隊可以協同合作來追蹤指標。例如，電子商務網站可以追蹤從「產品詳細資訊」微型前端到「購物車」微型前端的使用者旅程，以測量參與度、流失和問題。如果每個微型前端都使用單一程式庫記錄事件，您可以整體取用此資料、進行整體探索，並識別有洞見的趨勢。

## 提醒
<a name="alerting"></a>

與記錄和監控類似，提醒 受益於使用空間進行標準化，以獲得一定程度的靈活性。不同的團隊可能對功能和非功能提醒做出不同的反應。不過，如果所有團隊都有根據在共用平台上收集和分析的指標啟動提醒的合併方式，則業務可以識別跨團隊問題。此功能在事件管理事件期間很有用。例如，警示可以透過下列方式啟動：
+ 特定瀏覽器版本上的 JavaScript 用戶端例外狀況數量增加
+ 轉譯超過指定閾值的時間大幅降低
+ 使用特定 API 時 5xx 狀態碼的數量增加

根據系統的成熟度，您可以在基礎設施的不同部分上平衡工作，如下表所示。


| **採用** | **研究和開發** | **Ascent** | **成熟度** | 
| --- | --- | --- | --- | 
| 建立微型前端。 | 實驗、記錄和分享學習。 | 投資工具來堆疊新的微型前端。簡化採用。 | 整合用於 scaffolding 的工具。推送以採用。 | 
| 端對端測試微型前端。 | 實作手動測試所有相關微型前端的機制。 | 投資用於自動化安全性和效能測試的工具。調查功能旗標和服務探索。 | 整合用於服務探索、生產測試和end-to-end測試的工具。 | 
| 發行微型前端。 | 投資共用 CI/CD 基礎設施和自動化多環境版本。簡化採用。 | 整合 CI/CD 基礎設施的工具 實作手動復原機制。推送以採用。 | 建立機制以在系統和業務指標和提醒上啟動自動轉返。 | 
| 觀察微型前端效能。 | 投資於共用監控基礎設施和程式庫，以一致記錄系統和業務事件。 | 整合用於監控和提醒的工具。實作跨團隊儀表板來監控一般運作狀態，並改善事件管理。 | 標準化記錄結構描述。成本最佳化。根據複雜的業務指標實作提醒。 |