我们上周介绍了怎样对用于扩展云应用程序的代码进行评估。我们现在要将目光投向那些编码及系统方面的改造策略，这些策略很可能随着时间的推移让系统变得愈发脆弱。因为CRM系统那看似永无休止的发展需求，我们代码的耐久度将成为能否长期顺畅运行这些系统的关键因素。

　　但是在开始之前，我需要声明一点：我所举出的使用实例及条款只适用于Salesforce.com环境;其它应用环境及平台所使用的是不同类型的协议(甚至是不同的抽象结构)，鉴于我对那些内容并不十分了解——所以请不要误以为我是个玩命帮Salesforce.com造势的五毛党。

　　声明式开发与编程之间的利弊关系

　　云计算基础应用程序更偏爱供应商所说的“声明式开发”，由于这种方式明确、易于学习且在SaaS环境下更易于控制。大多数云计算应用程序会带来繁重的信息组验证规则、信息组及列表约束以及对象方面的工作流程。过去这种方式颇为有效，原因是它提供了数量惊人的处理能力及功能。

　　但是当我们需要向其中添加新代码，特别是会创建新记录的代码时，麻烦就会随之而来。在开发新的触发器、类或集成化“监听”服务的时候，编码者很可能会在特定的开发环境或沙箱环境中进行工作，而这些环境的配置很可能和生产系统本身并不匹配。当代码被加入产品的时候，各种错误状况往往层出不穷——而且通常无法在开发环境中进行返工。遗憾的是，错误信息不仅对用户来说非常讨厌，甚至还不能为故障排查提供足够的线索。

　　第一组提示：

　　(1)确保开发工作在最新更新的“沙箱”环境中完成，这样开发人员就不会头痛于其与生产环境之间的配置差异了。

　　(2)在可能的情况下，在沙箱中最大程度启用集成适配器及其它插件，这样一来开发人员就可以看到状态变化(特别是从外部来源所‘映射’得出的错误状态)所引起的后果。

　　(3)一旦大家开始针对对象开发扩展及功能，务必删除全部验证规则并在低级代码中重新加以实施，这样我们才能预见可能出现的陷阱及控制误差条件。

　　(4)出于同样的目的，大家要把任何将会引发信息组更新的工作流部署于低级代码当中。

　　(5)创建一套管理规则，并且保证其难以创建新的验证规则或是能引发信息组更新的工作流。

　　(6)必须保证代码能够为信息组或是约束条件列表提供保护，对值的预检查将帮助我们规避棘手的难题。

　　(7)通过检查确保每个信息组为NULL，且每个集、列表或者映射都为空，之后大家才能尝试在逻辑关系中加以使用(没错，甚至在一切错误检查逻辑关系中也是如此)。

　　(8)正如之前提到的“云计算中的错误处理”话题，为实时掌握所有应用程序错误编写类，并将其作为消息发送至云计算中的集中式错误日志服务处。

　　尽可能以列表为核心

　　大家都知道，在类或者触发器当中对值进行硬编码不是什么好主意，所以我们至少应该将这些参数部署于每个模块的声明区段中。或更进一步，将这些变量移动到查找列表或者资源文件之类每当代码运行都会加载的部分里。

　　虽然数据库越来越标准化，且几乎一切内容都可被添加进查找列表当中，这种做法仍然有些过于抽象且宽泛。过度追求指针引导让任何除原始开发者之外的人士很难理解，并会造成应用程序运作缓慢(甚至会影响到云环境的调速器限制)。所以以下提示就变得非常重要：

　　(9)务必将配置参数(例如选择列表的赋值、获许状态或者配置选项等)添加至查找列表中。务必在每个查找列表中包含批注行，并保证他人能通过阅读这些备注理解列表及值的语义、行为以及更新记录。如果大家的云系统能支持，还应将该列表保存在内存(‘自定义设置’)中，以避免由磁盘读取带来的高延迟。

　　(10)务必将这些查找列表置于配置控制下。至少要锁定访问行为，并确保此类列表得到定期备份。

　　(11)不要懒于为列表及信息组命名——一时轻松往往会在故障排查中给你带来巨大的麻烦。

　　上面这些提示对于阿里云应用开发很有帮助。

　　云计算要求敏捷、XP或TDD(即时分双工)类型的编码风格，同样适用与如阿里云这些各大云计算公司。

　　我不太了解那种排除了大型模块、瀑布式开发或者大量嵌套/分支化内容的云环境是个什么样子，不过大家应该偶尔会碰上这种实例。不过为了一劳永逸，我们必须抛弃这样的做法，因为它完全不利于打造牢固、持久的代码。

　　(12)对象不只是针对UI。它们的存在是为了支持可理解性、重调用及代码重构。但千万别犯傻;对象对可理解性的支持是一切的前提——失去了可理解性，其它各种益处都将烟消云散。

　　(13)保证模块小巧、简单且可分离。仔细阅读KISSS原则，该原则同样会使测试及调整工作更为轻松。

　　不要躁进，关注平台的局限

　　云计算平台会给特定类型的执行内容(例如数据库查询或者内存内列表创建等)带来局限。因此如果大家是第一次开发功能性产品，必须确保自己的首个发行版本不能超过资源指标上限的50%。因为不久之前大家必然会面临新的需求及应急手段，这些都会带来更大的资源消耗量。

　　(14)尽量使用内存缓存中的数据(例如‘bulkification’以及‘动态SQL’)，而不是每次都劳烦数据库。多利用未来及成批的类来处理大量工作负载和数据集。

　　(15)除非有什么硬性设计原因，不然必须确保我们的测试代码获得100%的代码涵盖率。不要只为闲置代码搞演习，而应对逻辑结果进行实际测试(通过正面及负面测试反复验证)。此外，不要把无操作状态填进代码中，借以人为抬高统计数据的覆盖率。