收藏贴！Salesforce开发课程必看的10个Apex最佳实践

Apex是一种强类型的，面向对象的编程语言，开发人员通过Apex表现业务逻辑来补充Salesforce平台所需的功能。Apex与Java很像，可以通过各种用户启动的事件来触发，例如记录更新，单击按钮，对象触发或外部Web服务请求。

本篇文章总结了10个Apex最佳实践，在你的职业道路上一定能用得上！

代码的批量化使代码能够一次有效地处理多条记录。这主要适用于Trigger，一次最多可以运行200条记录。

下图中是一个没有考虑批量化代码的示例。在Trigger中，只处理第一个机会，其他任何机会都保存在同一个Transaction中。根据业务流程，这可能是一个灾难性的错误。

下面是为处理Trigger中的整批记录而设置的相同代码，这意味着在一次Trigger调用中将正确处理200条记录。

我们还可以对代码进行批量化，以帮助提高一段代码的性能，从而减少查询以及其他操作。

与迭代列表相比，使用映射可以通过减少要执行的总代码行数来大大降低代码运行的复杂性和时间量。

如何一次插入/更新多条记录？或根据特定上下文查询记录集？亦或是在for循环中，在这些记录上查询或运行DML？

SOQL和DML是可以在Apex中执行的操作，两者都有与之相关的严格的Governor Limits。因此，将它们固定在一个循环中会导致灾难。

对于DML语句，可以将这些语句移出循环。在循环中将希望对其执行操作的记录添加到一个列表中，然后在列表中执行DML语句。

将SOQL迁移到循环之外可能有点棘手。例如，当插入一个新的联系人时，计算客户的联系人数量。在这种情况下，我们希望遍历所有联系人，获取每个联系人的Id，并将其放入集合中。然后，使用“AccountId IN :accountIds”在集合之外执行查询，并将结果放入一个映射中。最后，再次迭代联系人，并从地图中获取客户。

Hard-coded ID在开发时可能运行正常且不会发生意外，但是一旦我们将代码迁移到生产环境中，这些ID将不再引用正确的记录。对于在沙盒中创建然后迁移到生产环境中的记录类型尤其如此。

如果需要使用记录类型，可以通过DeveloperName引用它们，这将在不同环境中保持一致。如果使用的ID需要与特定记录相关，可以将此ID存储到自定义元数据中并在运行时检索该值。

当在单个对象上定义多个Trigger时，当保存记录并调用Trigger时，无法保证Trigger的运行顺序，它是随机的。Trigger中的单个操作通常具有优先级顺序，或者它可能有先决条件（例如，分配Parent Lookup，然后预期将在下一个操作中填充）。

具有随机触发顺序也会在代码中引入随机性，这种随机性将增大调试和开发代码的难度，因为总是有随机性元素并且不能准确地复制场景。

将查询直接作为可迭代变量放在for循环中，而不是将查询结果分配给变量。这会导致查询执行方式发生一些变化，结果被更有效和透明地分块和处理，从而避免遇到限制。

值得注意的是，执行聚合查询时不适合SOQL for循环，这些查询不支持启用更有效分块的底层机制，如果结果返回超过2000行，则会引发异常。

将Apex代码部署到生产环境中时，Salesforce要求至少有75%的代码覆盖率。

仅为实现代码覆盖率而编写的测试，除了在特定的场景中显示外，它实际上并没有提供任何价值。在编写测试时，应该关注覆盖代码的不同用例，确保覆盖了代码实际运行的场景。

其中一些可能正在测试相同的方法而不生成额外的覆盖行，每个测试方法都在不同的场景下运行代码。例如，这可能涵盖Trigger中的正测试用例和负测试用例。运行测试后，需要验证代码是否确实执行了预期的操作，如果没有，则手动使测试失败。

这种测试能提供更多的价值，并且可以作为管理员添加一些新功能或更改不同代码段时可能出现的问题的早期预警系统。

嵌套循环有时无法避免。虽然嵌套循环不会遇到性能问题或Governor Limits，但会影响可维护性和可读性。

在代码块中添加循环，会增加认知复杂性，代码的理解难度增大。添加嵌套循环会增加这种认知复杂性，不同的开发人员很难直观地理解一段代码，需要更多的努力来调试或修改。

如果开发团队中的每个成员都遵循命名约定，好处显而易见。因此需要在项目开始之前就确定好命名约定，这在开发、维护和协作的过程中，将大大提高团队工作效率。

在编写Trigger时，如果将逻辑直接放在Trigger中，测试和维护就会变得非常困难。相反，应该使用Trigger来调用专门设计用于处理逻辑的类，然后轻松地测试、维护和重用这些类。通常将这些类称为 TriggerHandlers。这些TriggerHandler类接受来自Trigger的输入，最终调用保存编写的业务逻辑的特定类。

一个常见的陷阱是将所有逻辑和功能直接放入TriggerHandler或TriggerHelper类中，这会导致代码无法维护。单独的功能应该被分解成单独的类，由TriggerHandler调用。

对于具有比较简单Trigger的对象（例如仅调用单个操作），省略处理程序类并直接从Trigger内调用Trigger操作是有意义的。但是，在编写操作时应考虑到处理程序，并且应在Trigger的复杂性增加时立即迁移到处理程序。

当为Lightning组件编写@AuraEnable方法时，经常需要返回更复杂的数据结构，例如记录、自定义数据类型。

一种简单的方法是将这些对象序列化为JSON，然后在组件的JavaScript中反序列化它们。

这种方法实际上是一种反模式，可能会导致组件性能不佳。相反，应该直接返回这些对象，让平台处理剩下的事情。

将返回的数据转换为JSON会导致消耗大量内存并花费CPU周期将其转换为长的字符串。如果有一组相当复杂的处理正在进行，或者有大量记录要返回，这可能会遇到Governor Limits，或者组件性能变差。

当直接返回结果时，序列化为JSON由平台处理，超出了Governor Limits。结果也会自动转换回对象供组件使用，而无需执行更多JSON.parse() 操作。

- end -