程式碼品質模式


深入瞭解結構正確的 資源和成本最佳化 → 代碼組織

此合併模式頁面涵蓋「資源最佳化」的程式碼品質與維護性作法。其中包含標準與自訂程式碼決策、技術債務管理、設計標準、文件作法和管治的指引。這些模式有助於維持開發速度、降低瑕疵率,並啟用長期解決方案永續性。

模式

要尋找的位置良好的外觀
大規模績效✅ 測試會驗證陳述性解決方案是否符合預測資料量的效能需求。在 Full Copy Sandbox 中載入含實際資料的測試,可在生產部署前確認擴充性。
維護性分析✅ TCO 分析比較陳述性與自訂方法的長期維護負擔,包括升級工作、測試需求,以及未來小組的技能需求。
混合方法結構✅ 解決方案會在適當的情況下結合陳述性與程式設計方法。流程會協調高階邏輯,而 Apex 會處理複雜的計算。公式欄位會計算簡單衍生,而 Apex 會處理大量作業。
AppExchange 評估✅ 建立自訂程式碼前,請評估提供類似功能的現有 AppExchange 封裝。文件評估結果,包括已檢閱的封裝、產能差異和 TCO 比較。

模式

要尋找的位置良好的外觀
待處理項目可視性✅ 在待處理項目中追蹤的技術債務項目,其標籤清楚、內容說明程式碼需要改善的原因、保持為未解決的業務影響,以及估計的補救工作。無法排定或管理不可見的債務。
增量改善✅ 在功能開發期間套用的 Boy Scout 規則:保留比找到更好的程式碼。小組可在相關功能工作期間以增量方式補償債務,而不需要大型專屬重構專案。程式碼審查會驗證增量改善方式。
預防而非補救措施✅ CI/CD 中的品質門會在程式碼到達生產環境之前強制執行標準。程式碼掃描器、ApexGuru 和整合至提取要求驗證的複雜度度量。封鎖問題會防止合併直到解決為止。

反模式

要尋找的位置看起來怎麼壞
待處理項目管理⚡️ 以口頭確認但未在待處理項目中追蹤的技術債務。不會看見債務累積。一律延後償還債務以支援功能工作。速度逐漸下降,小組無法解釋原因。
品質門略過⚡️ CI/CD 品質門經常在排程壓力下略過,意圖稍後修正。「稍後」永不發生。程式碼掃描器失敗標記為已知問題且已忽略。為了配合不良實作而增加的複雜性值。
無補救能力⚡️ 配置給功能工作的 100% 衝刺容量,其容量為零,可補償技術債務。債務會無限期累積。每 18-24 個月需要一次的主要重構專案耗用整個季度。
組態債務⚡️ 自訂中繼資料類型與自訂設定會在沒有清除的情況下累積。未使用的組態會無限期保留。生產有 50 個中繼資料記錄,實際使用的記錄只有 12 個。沒有說明組態值目的的文件。

模式

要尋找的位置良好的外觀
觸發結構✅ 持續套用觸發處理常式模式:精簡觸發會委派給處理常式類別、處理常式類別會依觸發內容 (插入前、更新後) 組織邏輯,清除方法名稱會顯示目的。觸發檔案本身沒有商業邏輯。
服務層實作✅ 在與控制項、觸發及批次進入點分開的服務類別中壓縮的業務邏輯。服務類別可在不重複的情況下跨多個進入點重複使用。清除命名慣例 (AccountService、OrderProcessor)。
選擇器模式✅ 在每個物件的選取器類別中集中 SOQL 查詢 (AccountSelector、OpportunitySelector)。選取器方法會傳回一致的欄位集。LDV 最佳化變更已套用一次,會影響所有查詢。
存放庫模式✅ 在讓模擬資料來源測試的介面後移除的資料存取權。存放庫實作會壓縮查詢建立、快取和最佳化策略。業務邏輯取決於儲存庫介面,而非實作。
元件設計標準✅ Lightning Web 元件遵循單一責任原則、公開組態的內容、發出父系通訊的事件,專為撰寫和重複使用而設計。使用使用範例記錄的元件文件庫。
程式碼組織✅ 邏輯封裝結構群組相關類別。清除網域邏輯、資料存取、API 端點和整合轉接器之間的分隔。封裝相依性會以一個方向流動。

反模式

要尋找的位置看起來怎麼壞
觸發⚡️ 所有業務邏輯都直接內嵌在觸發檔案中,並具有深度巢狀的條件、沒有關注的分隔、沒有處理常式類別。300 多個條列觸發檔案混合驗證、業務邏輯和整合呼叫。無法有效測試。
迴圈中的查詢⚡️ 在迭代迴圈內執行的 SOQL 查詢。適用於小資料量,但在處理大量作業時違反 100 個 SOQL 查詢限制。只有在生產環境中觸發大量資料載入時才會發現。
迴圈中的 DML在迭代迴圈中執行的 DML 陳述式 (insert、update、delete)。使用大量作業違反 150 個 DML 陳述式限制。每個記錄都會在個別的資料庫交易中處理,而非有效率的大量處理。

模式

要尋找的位置良好的外觀
結構決策記錄✅ 儲存在版本控制項中的 ADR 中記錄的重要結構決策。ADR 會捕捉內容 (業務驅動因素、技術限制)、決策 (選擇的項目)、考慮的替代項目 (拒絕的原因),以及後果 (交易、重試的條件)。