---
schema_version: "1"
id: a1d107f6de3281569a8d67bc639e3fc3a9c12a9041de8142326e7226e22837a3
title: 代码质量模式
collection: architect
version: current
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/resource-and-cost-optimization-code-quality-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/resource-and-cost-optimization-code-quality-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 7e78b241e683cb829e30b3846e422d067201611028050d2883827c0202c71e1d
products:
  - 架构良好的框架
  - Architect Site Content Repo
---
# 代码质量模式

<br>

了解有关架构良好的[资源和成本优化](/docs/architect/zh-cn/well-architected/guide/resource-and-cost-optimization.html)的更多信息 → [代码组织](/docs/architect/zh-cn/well-architected/guide/resource-and-cost-optimization.html#code-organization)

此合并模式页面涵盖了资源优化的代码质量和可维护性实践。它包括关于标准与自定义代码决策、技术债务管理、设计标准、文档实践和治理的指导。这些模式有助于保持开发速度，降低缺陷率，并实现解决方案的长期可持续性。

## 标准与自定义代码策略

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 大规模绩效              | ✅ 测试验证声明性解决方案是否满足预计数据量的性能要求。在完全复制 Sandbox 中使用现实数据进行负载测试，这证实了生产部署前的可扩展性。 |
| 可维护性分析          | TCO 分析比较了声明性方法和自定义方法的长期维护负担，包括升级工作、测试要求和未来团队的技能要求。 |
| 混合方法架构       | ✅ 解决方案酌情将声明性和程序性方法结合起来。在 Apex 处理复杂计算时，流会编排高级逻辑。Apex 处理批量操作时，公式字段计算简单派生。 |
| AppExchange 评估            | ✅ 在构建自定义代码之前，请评估提供类似功能的现有 AppExchange 软件包。记录评估结果，包括审查的软件包、功能差距和 TCO 比较。 |

## 技术性债务管理

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 待办事项可见性            | ✅ 跟踪待办事项中的技术债务项目，带有明确的标签，上下文解释了代码需要改进的原因，未处理对业务的影响，以及估计的补救措施。无形债务无法优先处理或管理。 |
| 增量改进       | ✅ 在功能开发期间应用的童子军规则：保留比发现更好的代码。团队在相关功能工作期间逐步解决债务，而不是需要大型专用重构项目。代码审查会验证增量改进。 |
| 预防重于补救   | ✅ 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 语句（插入、更新、删除）。使用批量操作违反 150 DML 语句限制。每个记录都在单独的数据库事务中处理，而不是高效的批量处理。 |

## 文档实践

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 架构决策记录 | ✅ 版本控制中存储的 ADR 记录了重要的架构决策。ADR 捕获上下文（业务驱动因素、技术约束）、决策（选择的内容）、考虑的替代方案（拒绝的原因）和后果（权衡、重新访问的条件）。 |