保持簡單

已完成
避免將結構設計、應用程式程式碼和作業過度工程化。

促成最可靠解決方案的通常是您移除的項目,而非新增的項目。 簡化可以減少控制介面區,將效率低下的現象和潛在的設定錯誤或非預期的互動降到最低。 另一方面,過度簡化可能會引發單一失敗點。 請採用可以維持平衡的方法。

範例案例

Contoso Travel 正在收購及整合一間擁有一款熱門 Web 型旅遊應用程式的小型新創公司。 該應用程式受歡迎的原因來自與連鎖飯店和航空公司協商大幅折扣的商業模式,以及使用社交媒體進行密集且高度精準的行銷活動。

該新創產品的現有版本是在 Node.js 中開發,並且在裝載於內部部署資料中心與 AWS 之間的 VM 上執行。

將工作負載元件最小化

只有在元件可協助您達成目標業務值時,才會將元件新增至您的結構。 讓關鍵路徑保持精簡。

針對商務需求進行設計可以帶來容易實作和管理的簡單解決方案。 避免有太多重要元件,因為每個元件都是重大失敗點。

Contoso 的挑戰

  • 新收購的應用程式的其中一個元件有助於在使用者預訂之後直接在網站上收集意見反應。 此功能很少使用,因為大部分使用者都會跳過此功能。 具有強大的使用者意見反應迴圈機制,可透過公司主要用於推廣使用者互動的社交媒體帳戶來運作。 此機制明顯比網站的意見反應功能使用得更頻繁。

套用方法和結果

  • 在 Contoso Travel 品牌版應用程式的初始版本中,小組決定移除工作負載的網站意見反應元件。
  • 較小的程式碼基底可降低維護和作業的成本。 在此案例中,對商務需求沒有任何影響。

將您的軟體開發生命週期標準化

為程式碼實作、部署和流程建立標準,並加以記錄。 使用自動化驗證來識別強制執行這些標準的機會。

標準可提供一致性,並將人為錯誤降到最低。 標準命名慣例和程式碼樣式指南等方法可協助您維護品質,並讓資產在疑難排解期間更容易識別。

Contoso 的挑戰

  • 新創公司的開發小組並未定義很多開發和流程標準。 許多正在使用的程式庫在功能上有所重疊、未強制執行程式碼樣式,而且發行管道缺少使用自動化測試的正式發行閘道。
  • Contoso 工作負載小組意識到新程式碼基底的維護成本太高,因為樣式缺乏一致性,而且程式庫和設計模式的使用不一致。
  • 在實際執行環境中進行主要更新之後經常發生事件,有時需要復原更新或在部署中途執行 Hotfix。 這類部署問題的頻率會迫使小組在對實際執行環境發行更新時,採取全體總動員的支援模型。 更糟的是,頻繁出現的問題會透過不良的使用者體驗對 Contoso 的聲譽產生負面影響。

套用方法和結果

  • 接管新應用程式支援工作的小組,藉由強制執行編碼樣式、將一組常用的程式庫和設計模式標準化,以及根據自動化測試正式使用發行閘道,努力提升一致性。
  • 工作負載小組在實作這些變更時,遵守其標準文件要求。 所有正在採用的新工具、設計模式和樣式都經過徹底記載,讓小組能夠更有效率地了解及維護工作負載。 小組現在執行程式碼檢閱時,可以更輕鬆地識別標準中的偏差。

將您的作業和開發負擔降到最低

利用平台提供的功能和預先建置的資產,以協助您有效地達成業務目標。

這種方法可以將開發時間降至最低。 它也能讓您依賴已用於類似工作負載且經過嘗試和測試的做法。

Contoso 的挑戰

  • 針對 Contoso Travel 品牌下的初始版本,Node.js 解決方案會從 VM 移轉至應用程式服務,以利用該服務提供的許多原生可靠性功能。
  • 部署在 VM 上的版本包含檢測所需的大量自訂程式碼。

套用方法和結果

  • 在初始移轉至應用程式服務期間,小組能夠在應用程式服務中透過實作 App Insights 自動檢測來移除所有自訂檢測程式碼。
  • 小組也能夠利用其他數個原生 App Service 功能,例如自動調整、Key Vault 整合和區域性備援。

檢定您的知識

1.

為什麼要嘗試將工作負載中的元件數目降到最低?

2.

您的軟體開發生命週期有哪些元素應該標準化?

3.

移至 Azure 應用程式服務如何協助 Contoso 小組簡化其工作負載?