【10月26日，国外头条】上周，我们介绍了如何评估用于扩展云应用程序的代码。我们现在将注意力转向编码和系统修改策略，这些策略可能会使系统随着时间的推移变得更加脆弱。由于CRM系统看似永无止境的进化需求，我们代码的持久性将成为这些系统能够长期平稳运行的关键因素。但在开始之前，我需要说明一点：我引用的用例和术语仅适用于Salesforce.com环境；其他应用程序环境和平台使用不同类型的协议（甚至不同的抽象结构），鉴于我对这些内容了解不多-所以请不要误会我是一个50美分的人竭尽全力推广Salesforce.com.声明式开发和编程之间的优缺点基于云的应用程序青睐供应商所称的“声明式开发”，因为它明确、易于学习并且在SaaS环境中更易于控制。大多数云计算应用程序都需要大量的消息组验证规则、消息组和列表约束以及面向对象的工作流。这种方法在过去很有效，因为它提供了令人难以置信的处理能力和功能。但是，当我们需要向其中添加新代码时，尤其是创建新记录的代码时，麻烦就来了。在开发新的触发器、类或集成的“侦听器”服务时，编码人员很可能在特定的开发或沙箱环境中工作，其配置可能与生产系统本身不匹配。当代码投入生产时，各种错误情况往往会突然出现——而且通常无法在开发环境中进行返工。不幸的是，错误消息不仅让用户感到厌烦，而且它们甚至没有提供足够的故障排除线索。***来自小组的提示：1.确保开发工作在最新的“沙箱”环境中完成，这样开发人员就不必担心他们和生产环境之间的配置差异。2.在可能的情况下，尽可能在沙箱中启用集成适配器和其他插件，以便开发人员可以看到状态变化（尤其是从外部源“映射”的错误状态）所产生的后果。3.一旦你开始为对象开发扩展和功能，一定要删除所有验证规则并在低级代码中重新实现它们，这样我们就可以预测可能的陷阱并控制错误条件。4.出于同样的目的，我们希望在低级代码中部署任何会引起消息组更新的工作流。5.创建一组管理规则并确保很难创建新的验证规则或触发信息组更新的工作流。6、需要保证代码能够为信息组或约束列表提供保护。值的预先检查将帮助我们避免棘手的问题。7.检查以确保每个信息组都是NULL，并且每个集合、列表或映射在您尝试在逻辑关系中使用它之前都是空的（是的，即使在所有错误检查逻辑关系中）。8.正如前面在“云计算中的错误处理”主题中提到的，编写实时访问所有应用程序错误的类，并将它们作为消息发送到云中的集中式错误记录服务。尽可能以列表为中心大家都知道在类或触发器中硬编码值并不是一个好主意，所以我们至少应该在每个模块的声明部分部署这些参数。或者更进一步，将这些变量移动到类似于每次代码运行时加载的查找列表或资源文件中。尽管数据库变得越来越标准化，几乎任何东西都可以添加到查找列表中，但这种方法仍然有些抽象和广泛。过分追求指针引导，除了原始开发者之外，其他任何人都难以理解，并且会使应用变慢（甚至影响云环境的governorlimit）。因此以下提示变得非常重要：9.确保将配置参数（例如选择列表分配、权限状态或配置选项等）添加到查找列表。请务必在每个查找列表中包含注释行，并确保其他人可以阅读这些注释以了解列表和值的语义、行为和更新记录。如果您的云系统可以支持它，您还应该将列表保留在内存中（'自定义设置'）以避免磁盘读取导致的高延迟。10.确保将这些查找列表置于配置控制之下。至少，锁定访问权限并确保定期备份此类列表。11、名单和信息组不要偷懒——一时的轻松往往会给你的故障排除带来巨大的麻烦。云计算需要敏捷、XP或TDD（时分双工）类型的编码风格这种情况偶尔会发生。但我们必须一劳永逸地放弃这种做法，因为它完全不利于构建强大而持久的代码。12.对象不仅仅用于UI。它们的存在是为了支持可理解性、召回性和代码重构。不过，别傻了。对象对可理解性的支持是一切的先决条件——没有可理解性，所有其他好处都将丢失。13.确保模块小巧、简单且可拆卸。仔细阅读KISSS原理，这也使测试和调优变得更加容易。不要着急，关注平台限制云计算平台对某些类型的执行（例如数据库查询或内存列表创建等）施加了限制。因此，如果您是第一次开发功能性产品，一定要保证您最新发布的版本不超过资源指标上限的50%。因为不久之前，大家不可避免地会面临新的需求和应急措施，这会带来更大的资源消耗。14、尽量使用内存缓存中的数据（比如'bulkification'和'dynamicSQL'），而不是每次都去麻烦数据库。利用未来和批处理类来处理大型工作负载和数据集。15.除非有一些硬设计原因，否则我们必须确保我们的测试代码获得100%的代码覆盖率。不要只是对空闲代码进行演练，而是要实际测试逻辑结果（通过正面和负面测试反复进行）。另外，不要在代码中填充空操作状态以人为地扩大统计覆盖范围。原文链接：https://img.ydisp.cn/news/20220916/ijxyzw5ssvt.html
