---
schema_version: "1"
id: 56cea901afe8f4884e36da4cc1bd2e6ed3e9ecc873c931c1b6f393640b3a42df
title: 意圖
collection: architect
version: next
locale: zh-tw
portal_url: https://docs.salesforce.com/architect/next/zh-tw/well-architected/guides/intentional.md
canonical_url: https://staging.architect.salesforce.com/docs/architect/zh-tw/well-architected/guide/intentional.html
source_site: staging.architect.salesforce.com
content_type: documentation
content_hash: 230c5eb8373844cd586d896e879646d00515ae68e575f8e60c601f1d28b24b35
products:
  - 結構良好
  - Architect Site Content Repo
updated_at: 2024-07-01T00:00:00Z
---
> [在此](/docs/architect/zh-tw/well-architected/guide/contributors)閱讀我們的更新排程。

## 簡介

意圖解決方案會立即與隨著時間提供業務價值。意圖結構會以策略的方式進行規劃和傳送、有效地進行維護,且對人類很容易閱讀和理解。

系統會以對業務和技術專案關係人一樣透明的方式排定功能和修正,並提供優先順序。工程選項可建立簡易供傳送和維護小組使用的實作,而不會新增功能或複雜。意圖結構更容易與業務一起擁有、維護和發展,因為其遵循明確且一致的實作模式。產生器可以解譯和實作新功能的設計,而維護小組可以瞭解已實作項目的文件。

您可以透過專注於三個關鍵區域:策略、維護性和可讀性,來建立更有意圖的系統。

## 策略

結構中的策略表示系統經過謹慎的規劃和交付。這表示運送和維護小組能夠清楚瞭解今天和未來要完成的工作,且每個人都瞭解要完成工作的「原因」。這表示緊急要求可以有效率地分級,利害關係人可以清楚地瞭解要求的影響和權衡。

您可以透過專注於優先順序、藍圖和管治,在結構中建立更明確的策略。

### 優先順序

優先順序表示規劃您要提供工作的順序和範圍。排定優先順序涉及瞭解可交付對業務的真實影響,並根據其他工作要求評估這些影響,以及產品或計畫的整體藍圖。

評估指定工作項目的影響的一個方法是查看業務的實際成本或效益。識別自動化的 [KPI](/docs/architect/zh-tw/well-architected/guide/automated#kpi) 後,您可以使用 [業務影響計算工作表](/docs/architect/zh-tw/resources/guide/kpi-spreadsheet-template)來評估實作的整體成本或益處。這些計算可協助您取得專案關係人的對齊方式,並讓專案關係人瞭解要建立的自動化以及其順序。它們也可以協助您找出要延後或避免的自動化。如需自動化,請參閱 [流程設計](/docs/architect/zh-tw/well-architected/guide/automated#流程設計) 以瞭解識別有效工作的詳細資訊。

建立傳送的優先順序架構也可協助您和您的維護小組管理使用者期望,並與您的藍圖保持一致。

您可用於排定優先順序的一些考量事項包括:

- 可交付項目的業務影響 (成本/益處)
- 可交付項目的必要新工作量
- 維護可傳遞所需的工作量

下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#策略模式與反模式)清單顯示適當 (與不良) 優先順序在 Salesforce 工作的外觀。您可以使用這些項目來驗證您的實作計畫,或在建立前找出需要更進一步識別優先順序的位置。

若要深入瞭解 Salesforce 提供的工具,以協助排定優先順序,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。

### 路線圖

藍圖是要執行之動作的已排定優先順序、經過驗證且已正確定義的檢視。有效的藍圖可讓您清楚瞭解未來工作的業務影響和技術影響。與您的企業和技術專案關係人互動是藍圖的關鍵部分。「藍圖」可讓您在任何工作開始前取得方法和成果的回饋意見和取得意見。最後,藍圖可讓每個利害關係人瞭解為什麼要提前工作。

如果您的小組使用待處理項目,請務必瞭解您的藍圖不是待處理項目摘要或清單。關係相反:只有在項目能夠清楚且可靠地繫結至您藍圖上可提供的項目時,才會進入待處理項目。在利害關係人的參與下建立的高品質藍圖,可讓傳送和維護小組清楚瞭解他們應專注在哪些項目以及應如何排定要求的優先順序,進而更輕鬆地排解衝突的要求並管理利害關係人的期望。

藍圖不良或不存在會導致:

- 新功能與功能何時可供使用的清晰度不足
- 利害關係人之間的優先順序衝突
- 提供的解決方案與整體組織願景之間的中斷連線
- 無法瞭解正在進行的工作
- 跨小組的不平均工作量
- 工作項目之間關係與相依性的可視性不足
- 由於管理不良相依性而導致實作延遲

利害關係人通常需要符合其角色的資訊,才能做出決策。建立有效的藍圖需要清楚瞭解您的受眾以及其所需的資訊類型。藍圖分為兩種樣式,以支援業務和技術受眾。每個樣式都包含兩個層級的細微度,以支援不同類型的資訊。

業務藍圖可協助利害關係人計畫組織變更、利用成長機會,並掌握公司目標。業務藍圖也可讓您確保 IT 支出符合整體業務願景。

- 建立業務功能藍圖,以向主管專案關係人顯示要啟用的功能。此類型的藍圖包含功能本身的概況詳細資料,以及其與業務目標保持一致的方式,例如提升營運效率或啟動新產品線。
- 建立業務功能藍圖以逐層細分至特定功能,並在您需要協助業務專案關係人進行資源規劃、預算和變更管理時,顯示其支援功能。

技術藍圖可協助技術專案關係人進行預算和資源配置規劃。他們也可協助實作小組瞭解其專案的適用程度,作為整體全貌的一部分,並識別任何跨小組相依性。

- 建立技術系統藍圖以顯示要實作的特定系統,以及任何系統層級相依性。此類型的藍圖會顯示概況系統資訊,以及系統與業務功能之間的對齊方式。
- 建立技術元件藍圖,以逐層細分所要部署系統的特定元件,以協助處理資源規劃和啟用需求。此類型的藍圖會顯示元件層級資訊和實作需求 (例如宣告式開發、Pro-code 等等)。

請確保您的藍圖包含實際的時間表。常見的錯誤是僅包含實作系統所需的時間,而不考量完成相關活動所需的時間。這可能會導致實作小組成員的配置過多,且延遲時間超出預期。建立藍圖時,請考量完成下列項目所花費的時間:

- 所有新增與更新的功能文件
- 支援新功能所需的現有功能維護
- 支援整合所需的相關系統更新
- 專案小組在上線後立即提升支援
- 測試、訓練和變更管理

完全一致的業務和技術藍圖可傳達功能何時上線的整體檢視,以及其背後有哪些技術。下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#策略模式與反模式)清單顯示 Salesforce 組織的正確 (和不良) 藍圖外觀。您可以使用這些項目來驗證或改善您的藍圖策略。

若要深入瞭解可協助您建立藍圖的 Salesforce 工具,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。

### 監管

監管是您與利害關係人一起處理優先順序、決策和變更管理的結構。監管可讓您清楚說明如何做出決策和溝通。其提供一致的方式讓回饋意見和要求進入決策流程,並讓所有利害關係人瞭解維護和開發工作的狀態。監管有助於使版本管理流程清楚且一致,並協助所有小組成員瞭解其角色和責任。

若未適當管理,小組將會遇到各種問題,包括:

- 對重疊功能與功能的要求會臨時收到
- 實作小組會排定更具影響力的利害關係人的「更簡單」工作或要求優先順序,而不會適當考量業務價值、權衡或整體組織目標
- 缺少一致的批准與審查流程
- 不一致的版本步調與品質
- 在開發工作中有高瑕疵率、覆寫、衝突和冗餘工作

可能系統沒有有效的管治最明顯的跡象是發行速度緩慢且繁琐。請務必瞭解,管治系統的大小並非其效率的度量。事實上,精心設計的管治系統 (如同在許多大型企業中找到的系統) 可能會降低發佈的速度和頻率。

良好的管治是讓不良自訂難以超越開發的早期階段,並以可預測且一致的方式將正確的自訂新增至生產環境。

管治工作過度反應性。當問題 (例如過量的技術債務) 開始成為業務問題時,便會起始或重複。在許多情況下,不幸的回應是企業「鎖定」開發工作和版本,而非建立有效的 [設計標準](/docs/architect/zh-tw/resources/guide/design-standards-template)和建立自動化,以在開發人員工具鏈和來源控制系統中強制執行這些標準。

建立 Salesforce 管理系統架構時,請包含下列元素,並考量要回答的這些關鍵問題:

- **工作要求。**使用者如何要求功能或功能?如何報告程式錯誤?
- **優先順序和工作規劃。**誰會決定工作要求有何意義?工作範圍、優先順序以及接受或登出方式為何?
- **環境與發行規劃。**什麼是開發、測試和發行環境的銷售管道?誰會執行哪些動作來佈建、重新整理和提供存取權?誰會處理部署和驗證?變更如何及何時發行?您在 Salesforce 版本週期期間如何處理部署或環境?(如需此項目的詳細資訊,請參閱 [應用程式週期管理](/docs/architect/zh-tw/well-architected/guide/resilient#應用程式週期管理)。)
- **服務擁有權與生產支援。**誰支援哪些項目?誰會處理「Hot-fix」生產問題?這些項目如何測試和釋出?誰負責組織的整體安全性標準?

下方的[模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#策略模式與反模式)清單顯示 Salesforce 組織的正確 (和不良) 監管狀況。您可以使用這些項目來驗證或改善您的管治策略。

若要深入瞭解可用於管治的 Salesforce 工具,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。

### 策略模式與反模式

下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/easy-strategy)探索更多策略模式。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">模式</th>
            <th scope="colgroup">防模式</th>
        </tr>
        <tr>
            <td rowspan="2"><b>優先順序</b></td>
            <td><b>在您的文件中:</b>
            <br> - 所有新工作項目都有明確的業務價值度量 (例如,收入增加、流程最佳化節省成本等)
            <br> - 藍圖顯示根據業務值排定工作的優先順序</td>
            <td><b>在您的文件中:</b>
            <br> - 與工作相關的業務值不明確或不存在
            <br> - 藍圖不存在</td>
        </tr>
        <tr>
            <td><b>在貴公司內:</b>
            <br> - 已識別所有工作項目的實作與維護成本
            <br> - 系統會根據業務影響、需要提供的新工作量,以及需要維護的工作量,來排定功能要求的優先順序</td>
            <td><b>在貴公司內:</b>
            <br> - 與實作與維護功能相關聯的成本不明確
            <br> - 要求會以臨時或先進/先出為基礎來傳送</td>
        </tr>
        <tr>
            <td rowspan="2"><b>路線對應</b></td>
            <td><b>路線圖:</b>
            <br> - 為您的受眾量身打造的資訊 (業務或技術)
            <br> - 以正確的詳細資料層級傳達資訊
            <br> - 顯示開始與結束日期
            <br> - 顯示先決條件與相依性</td>
            <td><b>路線圖 (若存在):</b>
            <br> - 作為專案起始材料而非傳送的成品使用
            <br> - 不要協助使利害關係人和遞送小組保持一致
            <br> - 混合詳細資料層級 (例如,透過在相同的藍圖中包含系統和元件)
            <br> - 包含未針對受眾量身打造的資訊 (例如,相同藍圖內的業務功能與系統)</td>
        </tr>
        <tr>
            <td><b>在您的業務中:</b>
            <br> - 利害關係人瞭解工作項目的「原因」
            <br> - 遞送小組瞭解如何根據較長期優先順序評估待處理項目
            <br> - 小組瞭解誰要執行哪些動作以及如何管理相依性
            <br> - 工作是有意的,即使優先順序必須快速變更</td>
            <td><b>在您的業務中:</b>
            <br> - 工作從待處理項目中的一切提取,且沒有明確的「原因」
            <br> - 小組無法協調相互相依工作,且經常在不瞭解的情況下重複工作
            <br> - 工作通常為反應性
            <br> - 利害關係人經常對正在完成的動作感到挫折和困惑,並在提供新功能時感到自信</td>
        </tr>
        <tr>
            <td><b>管治</b></td>
            <td><b>在您的業務中:</b>
            <br> - 使用者可以輕鬆報告程式錯誤和要求功能
            <br> - 工作項目的優先順序流程已記錄並向所有利害關係人透明
            <br> - 已清楚記錄環境策略,且開發環境符合文件
            <br> - 發行規劃對所有遞送小組成員可預測且透明
            <br> - 小組成員瞭解在整個應用程式生命週期負責的項目
            <br> - 使用者和傳送/維護小組可以清楚瞭解版本
            <br> - 生產支援流程清楚明確,且 hot-fixes 具有生產的明確路徑
            <br> - 小組和專案僅使用已批准業務使用的 AI 模型</td>
            <td><b>在您的業務中:</b>
            <br> - 錯誤報告與功能要求為臨時
            <br> - 工作項目沒有明確的優先順序
            <br> - 環境為臨時佈建,且可能無法以預測的方式重新整理;開發人員通常沒有所需的環境和存取權
            <br> - 傳送小組和使用者無法預期發行版本
            <br> - 小組不知道誰負責哪些事項
            <br> - 臨時處理熱修復
            <br> - 您的待處理項目已成為過時且停滯的「計畫銀行」
            <br> - 管治機構會作為協助台來疑難排解支援要求
            <br> - 無法輕鬆存取文件
            <br> - 小組臨時選取 AI 模型</td>
        </tr>
    </tbody>
</table>

## 永續性

永續性表示系統可以保持在正常狀態,新功能會進入,技術債務會定期地以可預測的方式移出系統。可維護的系統可讓您的小組以可預測的速度和品質為業務提供價值。系統的維護性取決於數個因素,包括其可讀性、寬鬆的配對程度,以及其測試策略的完整性。

最重要的是,系統的維護性取決於其設計的直接性。本節涵蓋如何建立更直接的解決方案設計,並提升維護性。

您可以建立更容易維護的解決方案,方法是專注於兩個關鍵:使用標準而非自訂功能,以及處理技術債務。

### 標準與自訂功能

Salesforce 提供一系列預先建置的解決方案—Sales Cloud、Service Cloud 和許多 Salesforce 產業解決方案,以及建立您自己的自訂解決方案的彈性。支援 Salesforce 自有雲端解決方案的基礎服務也可供任何在 Salesforce Customer 360 Platform 上建立的自訂解決方案使用。使用 Salesforce 的預先建立服務和解決方案,作為盡可能多個解決方案的信任基礎。

使用預先建置平台服務有兩個不同的優點。首先,您的應用程式自然會在每個版本中受益於最新的 Salesforce 創新。其次,您的開發小組可以專注於擴充和深化 Salesforce 解決方案所提供的業務能力,而不是處理基本的結構繁重工作。

從結構的角度來看,正確選擇何時使用標準功能以及何時建立自訂功能並不具有挑戰性。索引鍵為:

- **自訂平台表示修改和擴充,而非複製**。當您設計或評估結構時,應詢問:此功能是否已存在於 Salesforce Platform 中的某一處?如果回答為「_是,但...\[在此插入業務利害關係人想要的變更...]」_,請使用平台中的預先建立功能。要完成的結構工作是找出最有用的方式來設定預先建立的 Salesforce 功能,以符合業務期望。
- **沒有任何自訂內容無缺**。隨著時間的推移,每個變更都會有後果。如果您需要實作自訂解決方案,您可以選擇盡可能使用低程式碼技術,並在實作中建立可[組合單位,以](/docs/architect/zh-tw/well-architected/guide/composable)減輕系統將產生的不可避免的[技術債務](/docs/architect/zh-tw/well-architected/guide/intentional#技術債務)。
- **考量 build-buy 頻譜**。[Salesforce AppExchange](https://appexchange.salesforce.com/) 是可擴充 Salesforce 的應用程式和解決方案市集。AppExchange 應用程式可以提供功能,而不需要建立和維護自訂解決方案的負擔。評估 AppExchange 解決方案時,請考量下列事項:
  - 識別解決方案的功能與間隙。在理想情況下,您會找到符合您所有業務需求的應用程式。實際上,您可能找不到完美的適配。當您評估解決方案時,請將潛在解決方案中的功能對應至業務需求的優先順序清單。這將協助您找到最符合您最嚴重需求的解決方案。
  - 使用 Sandbox 和免費試用版。使用免費試用期間來評估 Sandbox 環境中的應用程式,並找出最合適的應用程式。判斷應用程式是否需要您進行與現有組態衝突的組態變更。
  - 考量短期與長期成本。根據訂閱式應用程式的循環成本評估長期應用程式維護節省的成本。避免您必須為業務專案關係人永遠不會使用的許多功能支付循環成本的情境。
- **使用 Salesforce 的預先建立資料模型。**Salesforce 提供銷售、服務和各種產業垂直的預先建立資料模型。使用 Salesforce 提供的資料模型可確保系統中的功能僅定義一次 (消除冗餘與孤立狀況)、在整個系統中建立單一事實來源、透過分析更容易瞭解應用程式資料、更容易使用 Salesforce 預先建置的人工智慧服務、降低維護成本 (透過減少您需要支援的自訂項目),並減少技術債務。

如此簡單。如您在下方的 [模式和反模式](/docs/architect/zh-tw/well-architected/guide/intentional#維護模式與反模式)中所見,反模式主要是複製自訂解決方案中的標準功能,或使用更複雜的技術來提供自訂。

在實際上,您可能會遇到一個情況,即業務專案關係人將自訂功能反模式視為最佳或唯一可行的進展方式。在這些情況下,您必須向利害關係人說明選擇此路徑所涉及的權衡,然後完整記錄決策、其原因和實作。這也是提供早期核心價值並隨著時間調整的區域,可協助您的利害關係人進一步瞭解前進的最佳方式。

若要深入瞭解可協助您提升維護能力的 Salesforce 工具,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。

### 技術債務

技術債務是任何系統的自然部分。當技術或業務需求改變時,昨天的音效設計可能會變成反模式。或許為了填補 Salesforce 平台功能缺口而建立的項目,會在新的 Salesforce 版本或產品啟動時突然變成冗餘。更高效能或彈性的技術可能會取代您已實作的技術。技術債務可透過許多方式建立。

使用 Salesforce Customer 360 Platform 建立應用程式的關鍵優點是平台內建的[回溯相容性](/docs/architect/zh-tw/fundamentals/guide/architecture-basics#平台-api)。這表示新平台創新可能會改變您應用於解決方案進展的模式,但您在先前 Salesforce 技術上建立的解決方案其日常功能仍會繼續運作。隨著時間的推移,任何以舊技術為基礎的解決方案都會開始造成新功能新增至應用程式的風險或瓶頸,並降低整體解決方案運作狀況。

規劃並執行定期工作以解決技術債務,對於在 Salesforce 解決方案中維持健康且直接的設計至關重要。無法規劃、稽核和補救技術債務是建立結構不良系統的確實方式。

將技術債務降到最低的方法之一是盡可能避免導入技術債務,方法是避免使用捷徑,並且偏好使用[標準功能而非自訂功能](/docs/architect/zh-tw/well-architected/guide/intentional#標準與自訂功能)。快速鍵 (如硬式編碼值) 可能有助於節省時間,但在長期內會產生必須償還的債務。

從結構角度解決技術債務的關鍵包括:

- 識別動作與不動作對業務的實際[成本或益處](/docs/architect/zh-tw/resources/guide/kpi-spreadsheet-template)
- 適當的 [路線圖](/docs/architect/zh-tw/well-architected/guide/intentional#路線圖)
- 建立[可組合解決方案](/docs/architect/zh-tw/well-architected/guide/composable)

難以讓利害關係人與採取行動保持一致。某些利害關係人可能會將持續維護視為解決「昨天的錯誤」,或移除他們想要預算支援的功能。

顯示動作與未動作的實際業務影響,以及清楚定義的可運送項目與時程表,可協助您的利害關係人瞭解處理技術債務的價值與相對優先順序。一律執行工作,將技術債務與業務影響連結在一起,不僅有助於您的利害關係人進一步瞭解待完成的工作。這也會協助您確保以實際有利於使用者的方式來識別和解決技術債務。

下方的[模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#維護模式與反模式)清單顯示 Salesforce 組織的正確 (和不良) 技術債務管理外觀。

若要深入瞭解可協助您處理技術債務的 Salesforce 工具,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。

### 維護模式與反模式

下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/easy-maintainability)探索更多可維護的模式。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">模式</th>
            <th scope="colgroup">防模式</th>
        </tr>
        <tr>
            <td rowspan="5"><b>標準與自訂</b></td>
            <td><b>在您的設計標準中:</b>
            <br> - 有明確的指導原則可防止解決方案不需要自訂
            <br> - 解決方案的指引原則使用下列優先順序:1.使用內建平台服務、2.在建立自訂解決方案前,請先考量 AppExchange 應用程式。在撰寫程式碼前使用低程式碼自訂項目</td>
            <td><b>在您的設計標準中:</b>
            <br> - 設計標準不存在或沒有避免不需要自訂和程式碼的明確理由</td>
        </tr>
        <tr>
            <td><b>在您的文件中:</b>
            <br> - 當選擇建立或購買解決方案時,決策記錄會顯示近期和長期成本的計算</td>
            <td><b>在您的文件中:</b>
            <br> - 當選擇建立或購買解決方案時,決策記錄不會同時考量近期與長期成本</td>
        </tr>
        <tr>
            <td><b>在資料模型中:</b>
            <br> - 沒有任何物件具有重複標準物件的名稱或功能
            <br> - 標準物件不會用於遠超出預期範圍的用途</td>
            <td><b>在資料模型中:</b>
            <br> - 物件會複製標準物件的名稱和/或功能
            <br> - 標準物件用於遠超出預期範圍的用途</td>
        </tr>
        <tr>
            <td><b>在 LWC、Aura 或 Visualforce 中:</b>
            <br> - 沒有可覆寫標準頁面檢視機制的程式碼</td>
            <td><b>在 LWC、Aura 或 Visualforce 中:</b>
            <br> - 存在程式碼來覆寫標準頁面檢視機制,通常是單一頁面應用程式的形式</td>
        </tr>
        <tr>
            <td><b>在 LWC、Aura 或 Apex 中:</b>
            <br> - 沒有程式碼嘗試覆寫或略過執行平台順序</td>
            <td><b>在 LWC、Aura 或 Apex 中:</b>
            <br> - 程式碼嘗試覆寫或略過平台執行順序</td>
        </tr>
        <tr>
            <td rowspan="3"><b>技術債務</b></td>
            <td><b>在您的藍圖中:</b>
            <br> - 已計畫處理技術債務的工作
            <br> - 交付與開始/結束日期清楚</td>
            <td><b>在您的藍圖中:</b>
            <br> - 未計畫處理技術債務的工作
            <br> - 交付項目不明確;開始/結束日期不明確</td>
        </tr>
        <tr>
            <td><b>在您的決策記錄中:</b>
            <br> - 清楚記錄前/後技術補償債務的 KPI
            <br> - 對動作與未動作的權衡討論,專注於業務成本或益處</td>
            <td><b>在您的決策記錄中:</b>
            <br> - 技術償還債務沒有可測量的 KPI
            <br> - 技術債務會以技術或 IT 重點的術語考量,與業務無關</td>
        </tr>
        <tr>
            <td><b>在您的組織中:</b>
            <br> - 未啟用任何不支援或舊版技術,包括:
            <br> -- 所有使用者都在 Lightning Experience 中工作
            <br> -- 在 Apex 中沒有或非常少使用 <code>@future</code> (使用 Queueable)
            <br> -- 所有第三方 Apex 都屬於 AppExchange 封裝
            <br> -- 沒有啟用的工作流程規則 (使用流程)
            <br> -- 沒有啟用的流程產生器程序 (使用流程)
            <br> -- PushTopic 事件 (使用「變更資料擷取」)
            <br> -- 一般事件 (使用平台事件)
            <br> -- 30.0 版之前的 API 版本
            <br> -- Salesforce 組織連線使用 Salesforce Connect 的跨組織轉接器</td>
            <td><b>在您的組織中:</b>
            <br> - 不支援或舊技術已啟用,包括:
            <br> -- 在 Salesforce Classic 中工作的使用者
            <br> -- Apex 中的 <code>@future</code> usage
            <br> -- 來自非 AppExchange 來源的第三方 Apex
            <br> -- 工作流程規則
            <br> -- 流程產生器流程
            <br> -- PushTopic 事件
            <br> -- 一般事件
            <br> -- 30.0 版之前的 API 版本
            <br> -- Salesforce 到 Salesforce 連線</td>
        </tr>
    </tbody>
</table>

## 可讀性

*可讀性*的概念的核心是建立一致性,讓人們能夠輕鬆瞭解事物的運作方式。建立可讀取系統可讓傳送與維護小組保持一致,並協助對系統不熟悉的人員快速瞭解組件的整合方式。這表示您的小組可能較不依賴具有機構或歷史 Knowledge 的人員,以有效地引導廠商或新小組成員。這表示小組中的技能人員可以專注於所做的選擇的品質和權衡,因為系統的組態和程式碼對人類很容易讀取和理解。可讀性可加速管理和品質保證流程,並協助小組在何時建立冗餘自訂項目。其也會增加具有可重複使用和可測試方式運作之系統的機會。

您可以透過有效的設計標準和文件來提升可讀性。

### 設計標準

[設計標準](/docs/architect/zh-tw/resources/guide/design-standards-template)提供指引,讓所有自訂都保持一致,即使是在開發的最早階段。設計標準的運作方式與護欄相似,讓所有運送小組和維護小組在系統上工作,都能掌握如何進行自訂和實作。定義設計標準有助於提升傳送和維護小組的生產力、讓程式碼和結構審查更容易執行,並為更好的[文件](/docs/architect/zh-tw/well-architected/guide/intentional#文件)提供基礎。

若沒有設計標準,小組較有可能在單間工作。若沒有設計標準所提供的一致性,企業將會遇到下列問題:

- 廠商和開發小組在解決方案之間使用臨時模式和方法,進而可能導入反模式並減少可重複使用性 (請參閱 [關注分隔](/docs/architect/zh-tw/well-architected/guide/composable#分離疑慮))。
- 增加解決生產問題的時間,以及引導新小組成員的必要支援小組,並協助他們瞭解不同的模式和方法集。
- 跨小組協同合作不佳、跨小組工作的冗餘、解決衝突所花費的時間,以及整合測試期間發現的錯誤。
- 挫折感和營業率增加。

設計標準的主要優點來自利害關係人必須進行的對話和決策以建立標準。具體而言,此流程為您的業務和技術負責人提供機會,讓他們能夠配合業務的最佳設計。

在您的 [設計標準中](/docs/architect/zh-tw/resources/guide/design-standards-template)包含下列內容

- Salesforce 中繼資料的 **命名慣例**。定義一組慣例,用於定義系統中每個自訂的命名方式。良好的命名慣例不僅會強制執行物件、欄位、程式碼、流程和系統其他元素的名稱的一致性。良好的命名慣例也可協助開發小組使用名稱來傳達其正在建立之目的與功能的相關資訊。因此,其他利害關係人只需查看其名稱即可更進一步瞭解特定自訂。
- **已批准的設計模式及其使用個案**。建立「[模式與防模式探索器](/docs/architect/zh-tw/well-architected-tools/guide/patterns)」庫,以及使用每個模式時機 (及不使用時機) 的重要資訊。文件庫可能包含必要的 Apex 觸發模式,或根據您在系統中所需的可[組合性](/docs/architect/zh-tw/well-architected/guide/composable)包含流程協調流程模式。
- **開發環境與工具指引**。維護開發小組用於其工作之工具的清單。這可能包含任何撰寫程式碼的人員所批准的工具鏈和語言,或已 (或尚未) 批准用於低程式碼開發的陳述性功能。您的標準可能包含自訂和文件的來源控制系統清單,以及必要的簽到/簽退步驟。也可以包含用於不同類型開發工作的環境清單。

除了定義這些標準外,您還需要決定維護與儲存標準的方式與位置。如果貴公司的小組找不到您的設計標準 (或甚至不知道其存在),則這些標準將無法生效。理想情況下,您的設計標準會與文件位於相同的系統內 (如需詳細資訊,請參閱下一節)。

下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性模式與反模式)清單顯示 Salesforce 組織的正確 (和不良) 設計標準外觀。您可以使用這些項目來驗證或改善您的設計標準。

若要深入瞭解可協助您定義設計標準的 Salesforce 工具,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。

### 文件

文件說明系統的功能、方式和原因。若沒有有意義且一致的文件,小組會浪費大量時間嘗試瞭解系統的原狀 (以及可能誤解的功能和自訂項目)。

良好的文件需要時間才能建立。雖然大多數小組都同意文件對於大型專案很重要,但在進行快速變更 (例如組態更新或對自動化進行小幅微調) 時,可能會是一個誘人的步驟。不記錄您對系統進行的變更一律為反模式。略過文件可能會提前節省少量時間,但針對未正確記錄的組織進行疑難排解所需的時間會超過取消這些節省時間的時間。無論您計畫進行之更新的所需精力層級為何,請一律將足夠的時間包含在所有估計值中建立文件。

缺少清楚的文件可能會導致各種問題,包括:

- 花在重新處理現有實作的開發週期
- 重複對先前決策進行重複或困惑的討論
- 新增小組成員或廠商的上線時間更長
- 對具有機構或歷史 Knowledge 個人的過度相依性
- 可在整個業務中支援相同或類似功能的冗餘結構
- 無法將解決方案的目的和價值傳達給關鍵利害關係人

針對 Salesforce 解決方案,請維護文件:

- **解決方案概觀**。[圖表](/docs/architect/zh-tw/reference-diagrams/guide/introduction)可讓您與專案關係人以各種詳細資料層級將解決方案視覺化。Salesforce 圖表架構可協助您建立圖表,以顯示解決方案的業務功能,以及技術實作詳細資料。
- **決策記錄**。將考量選項、權衡、最終決策和推理的記錄保存在集中的位置,所有小組成員都可以存取以供日後參考。
- **代碼**。程式碼的格式本身是文件的關鍵,這可以 (且應該) 符合您的 [設計標準](/docs/architect/zh-tw/well-architected/guide/intentional#設計標準)。您也會想要有關鍵資訊的記錄,並在每次修改程式碼時進行更新。針對所有類別、觸發和元件,記錄以下內容:
  - 撰寫程式碼的人
  - 撰寫程式碼的時間
  - 程式碼應執行的動作
  - 主要相依性
  - 所有變更
- **宣告自訂**。針對您組織中可對中繼資料進行的每種自訂,Salesforce 會為小組提供 [內建屬性](/docs/architect/zh-tw/fundamentals/guide/platform-multitenant-architecture#瀏覽器型無程式碼和低程式碼應用程式開發),以提供有關中繼資料目的與意圖的實用資訊。作為設計標準的一部分,請包含小組如何使用這些內建功能,以及小組如何命名陳述式自訂。同時維護與您用於程式碼相同的金鑰資訊記錄。

開發一組文件標準,以確保所有目前和未來的小組成員都能夠以相同的方式解讀文件。 ([設計標準](/docs/architect/zh-tw/resources/guide/design-standards-template) 可為此提供協助。)請務必考量使用者如何搜尋文件以尋找相關的區段或字詞。隨著系統的年齡和複雜性增加,您的文件也會成長。您文件中資訊的實用性將直接與使用者搜尋及尋找相關項目的頻率、速度及輕鬆度有關。

下方的 [模式與反模式](/docs/architect/zh-tw/well-architected/guide/intentional#可讀性模式與反模式)清單顯示 Salesforce 組織的適當 (與不良) 文件外觀。您可以使用這些項目來驗證或改善您的文件策略。

若要深入瞭解 Salesforce 工具的文件,請參閱與意圖相關的 [工具](/docs/architect/zh-tw/well-architected/guide/intentional#與意圖相關的工具)。

### 可讀性模式與反模式

下表顯示要在組織中尋找 (或建立) 的模式選項,以及要避免或鎖定修復的反模式。

✨ 在「[模式與反模式探索器」中](/docs/architect/zh-tw/well-architected-tools/guide/easy-readability)探索更多可讀的模式。

<table>
    <colgroup>
       <col span="1" style="width: 10%;">
       <col span="1" style="width: 45%;">
       <col span="1" style="width: 45%;">
    </colgroup>
    <tbody>
        <tr>
            <th scope="colgroup"></th>
            <th scope="colgroup">模式</th>
            <th scope="colgroup">防模式</th>
        </tr>
        <tr>
            <td rowspan="2"><b>設計標準</b></td>
            <td><b>在您的組織中:</b>
            <br> - 程式碼和陳述式自訂項目具有一致且人類可讀的名稱
            <br> - 資料模型具有一致且統一的物件和欄位名稱
            <br> - 稽核顯示在報告中一致填寫和參照的欄位等。</td>
            <td><b>在您的組織中:</b>
            <br> - 程式碼和陳述性自訂項目沒有一致的名稱
            <br> - 資料模型名稱不一致,且許多物件和欄位似乎為冗餘
            <br> - 稽核會顯示許多未使用的欄位或不同層級的用量,且報告等沒有一致的連結。</td>
        </tr>
        <tr>
            <td><b>在您的業務中:</b>
            <br> - 小組瞭解要使用 (而非使用) 哪些工具來完成工作
            <br> - 通過使用個案輕鬆找到並識別批准的設計模式
            <br> - 已核准的 AI 模型會清楚識別並包含預期的用途</td>
            <td><b>在您的業務中:</b>
            <br> - 小組使用許多不同的工具完成類似的工作
            <br> - 沒有已批准的設計模式
            <br> - 廠商或新進員工需要很多時間才能上線
            <br> - 批准的 AI 模型未清楚識別,且其預期用途不明確</td>
        </tr>
        <tr>
            <td rowspan="2"><b>文件</b></td>
            <td><b>在您的組織中:</b>
            <br> - 程式碼和陳述性自訂項目具有明確的描述</td>
            <td><b>在您的組織中:</b>
            <br> - 程式碼和陳述式自訂項目沒有描述、具有難以理解的描述,或具有描述,似乎不符合自訂項目實際執行的動作</td>
        </tr>
        <tr>
            <td><b>在您的業務中:</b>
            <br> - 所有解決方案的業務功能圖表和技術實作詳細資料存在
            <br> - 金鑰誰/何時/存在的程式碼和陳述式自訂記錄資訊
            <br> - 人員可以搜尋並尋找相關文件</td>
            <td><b>在您的業務中:</b>
            <br> - 難以找到解決方案的什麼/如何/原因,且大多數的小組可能無法使用
            <br> - 人員難以瞭解解決方案以及其使用的系統
            <br> - 廠商或新進員工需要很多時間才能上線</td>
        </tr>
    </tbody>
</table>

## 與意圖相關的工具

<table class="tools-table"><tbody><tr><th>工具</th><th>描述</th><th>策略</th><th>永續性</th><th>可讀性</th></tr>
<tr><td><a href="https://github.com/SalesforceFoundation/ApexDoc">ApexDoc</a></td><td>使用靜態 HTML 頁面文件 Apex</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.fields_picklist_delete_inactive_values.htm&language=en_US&type=5&_ga=2.216886358.1142927923.1683068265-1808100124.1682614163">大量刪除未啟用的選項清單值</a></td><td>從選項清單中刪除未啟用的未使用值</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://www.lightningdesignsystem.com/tools/validator/">Lightning 設計系統驗證程式</a></td><td>驗證標記並瞭解如何改善程式碼</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=release-notes.rn_automate_flow_mgmt_migrate_to_flow_tool.htm&type=5&release=242&_ga=2.180751207.1142927923.1683068265-1808100124.1682614163">移轉至流程</a></td><td>將工作流程規則和流程產生器程序轉換為流程</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3u00000MRsKnEAL">Salesforce Labs 的專案管理工具</a></td><td>在您的 Salesforce 組織內管理專案</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode-expanded">Visual Studio Code 的 Salesforce 擴充功能 (展開型)</a></td><td>使用 Visual Studio 程式碼擴充功能有效率地分析 Salesforce 程式碼</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://sfdc.co/OrgCheck">組織檢查</a></td><td>快速分析您的組織及其技術債務</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://github.com/forcedotcom/code-analyzer">Salesforce 程式碼分析器</a></td><td>透過 IDE、CLI 或 CI/CD 掃描程式碼,以確保程式碼符合最佳作法</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://architect.salesforce.com/roadmaps/roadmap-explorer">Salesforce 藍圖探索器</a></td><td>探索 Salesforce 產品創新</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://help.salesforce.com/s/articleView?id=sf.admin_monitorsetup.htm&type=5">設定稽核追蹤</a></td><td>追蹤設定變更和稽核歷程記錄</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
</table>

## 與意圖相關的資源

<table class="tools-table"><tbody><tr><th>資源</th><th>描述</th><th>策略</th><th>永續性</th><th>可讀性</th></tr>
<tr><td><a href="https://www.salesforce.com/blog/documentation-strategies-to-improve-your-salesforce-org/">改善 Salesforce 組織的 5 個文件策略</a></td><td>改善 Salesforce 實作文件</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/choose-naming-conventions-sc">選擇命名慣例 (Trailhead)</a></td><td>瞭解如何套用命名慣例</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/defining-identifying-and-measuring-technical-debt-5f783e2b381d">定義、識別和測量技術債務</a></td><td>定義、識別和測量技術債務</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="/docs/architect/zh-tw/resources/guide/design-standards-template">設計標準範本</a></td><td>為您的組織建立設計標準</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="/diagrams">開始使用 Salesforce 圖表</a></td><td>瞭解如何為您的使用個案建立正確的圖表</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/get-started-with-coding-conventions-sc">開始使用程式碼慣例 (Trailhead)</a></td><td>定義並遵循程式碼慣例</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/trailblazer-community/download/file/0693A000006PskRQAS">如何處理技術債務 (Trailhead)</a></td><td>在您的 Salesforce 組織中管理技術債務</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/success-cloud-coding-conventions/improve-your-apex-code-sc">改善您的 Apex 程式碼 (Trailhead)</a></td><td>套用以測試為導向開發的基本原則</td><td class="check-col"></td><td class="check-col"></td><td class="check-col">X</td></tr>
<tr><td><a href="https://trailhead.salesforce.com/content/learn/modules/manage_the_sfdc_organizational_alignment_v2mom?trailmix_creator_id=strailhead&trailmix_slug=prepare-for-your-strategy-designer-credential">組織對齊方式 (Trailhead)</a></td><td>瞭解對齊方式的 V2MOM 流程</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/prioritizing-and-planning-a-way-out-of-technical-debt-6f18fbb2b007">排定優先順序並規劃技術債務退出之路</a></td><td>制定減少和移除技術債務的計畫</td><td class="check-col">X</td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://salesforce.quip.com/MW5cAPVwat8k#JCIACA8Q963">Salesforce 命名慣例範本</a></td><td>開始使用命名慣例</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col">X</td></tr>
<tr><td><a href="https://admin.salesforce.com/blog/2021/tech-debt-what-it-is-and-why-you-should-care">技術債務:它是什麼,以及您應該注意的原因? </a></td><td>瞭解組織中技術債務的影響</td><td class="check-col"></td><td class="check-col">X</td><td class="check-col"></td></tr>
<tr><td><a href="https://medium.com/salesforce-architects/using-the-business-model-canvas-in-enterprise-architecture-5c136803a99d">在企業結構中使用業務模型畫布</a></td><td>在業務模型中建立、傳送和查看值</td><td class="check-col">X</td><td class="check-col"></td><td class="check-col"></td></tr>
</table>

## 告訴我們您的想法

協助我們讓 Salesforce Well-Architected 與您相關;進行我們的[調查](https://sfdc.co/bxNtvh)以提供此內容的回饋意見,並告訴我們您接下來想要查看的內容。