如何避免云计算中的代码错误

　　上周我们报道了如何评估用于扩展云应用的代码。现在让我们来看一看让系统衰退的代码和系统修正方案。由于CRM系统的要求不断改进，代码的持久性成为了系统能够长期运行的关键因素。

　　声明式开发和编程之间关系紧张

　　云应用偏向于供应商所谓的“声明式开发”，因为它清晰明了、便于学习、也便于在SaaS环境中操控。大多数云应用会大量使用字段内验证规则和系统规定参数、字段和表格限制以及数据集的工作流。此方法适用于早期工作，并会提供惊人的功能和力量。

　　当添加代码，特别是添加可以创建新数据的代码时，问题就会出现。当开发新的触发程序、类或是一体化“监听器”服务时，编码器会在不同配置的开发环境或沙盘环境中工作。当代码被加入产品时，各种错误状况往往层出不穷并无法在开发环境中复写。不幸的是，错误信息会让用户感到窘迫，而且不会为故障检修员提供很多线索。

　　第一套建议：

　　1.确保开发者在最近更新的“沙盒”中工作，不要让他们对生产环境的配置感到惊讶。

　　2.尽可能让集成适配器和其他插件存在于沙盒中，以便开发者可以看到状态变化的分支（特别是外部情报源发射回来的错误条件“映像”）

　　3.一旦开始围绕一个对象开发扩展和功能，放下所有的验证规则，重新在低级的代码中执行扩展和功能命令，这样可以让你有预见地捕捉和控制错误情况。

　　4.以类似方式的方式，利用低级代码装置替换实现字段更新的工作流。

　　5.创建一个管理方针，加大创建验证规则和工作驱动字段更新的难度。

　　6.确保放入代码，为字段和表格限制提供保护，实质上是避免碰钉子，预先检查数值。

　　7.在逻辑（甚至是验错逻辑）中使用代码前，核对每个字段NULL为，每个集合、明细表和映射EMPTY。

　　8.如“云计算错误处理”中提到的，及时写出处理应用错误的类，以信息的形式发送到云计算其他地方的集中错误记录服务处。

　　尽量让表格控制

　　都知道把值写死在类和触发程序中不是个好主意，我们至少应该把这个参数放在每个模块声明部分的static-final变量中。甚至做得更好，把这些变量移入lookup函数表中或是代码运行的资源文件中。

　　虽然数据库好像已被标准化，并且几乎任何东西都能转为lookup函数，但是数据库还是很容易过于抽象和普通。过度的指针雕镂会降低原创者以外的人的理解，并会减慢应用程序的速度。（甚至会反推云环境的调节器限制）。因此将有下面几点建议：

　　9.把配置参数（如：选择列表值、准许声明、配置选择）放入lookup函数表中。在每个表中列出一个注释栏，让用户可以明白语义、行为、表格和数值的更新历史记录。如果你的云系统支持此功能，把这个列表放入内存（“自定义设置”）来减少磁盘读取的等待时间。

　　10.在配置控制下提交查询表。锁住入口并确保定期备份这些表格。

　　11.要勤于命名表格和字段——常常就是由于对此的马虎造成了修理故障。（如：想到一个名为“folly，”的表格）

　　我不太了解那些排除大组件、瀑布式开发或过多的嵌套/分支的云环境，大家每过一段时间就会遇见这种情况。但是为长远着想，我们需抛弃这些设计，编写可靠、持久的代码。

　　12.对象不只是为了UI，还为了支持理解性、重复使用和重构。但不要变得疯狂，要确保你的对象支持可理解性，否则实现其他益处则是海底捞月。

　　13.保持模块的小巧、简单和分离。核实KISSS原理也能更容易测试和调试。

　　云平台对某些工作进行强加的调节器限制，如数据库查询或是内存的表格创建。开始增进功能时，要确保消耗少于最初版本最大调节器限度的50%。不久后你就会有新的需求和消防演习，这意味着你需要更多的资源。

　　14.利用数据的内存缓存（“bulkification”和“动态SQL”），而不是每次干扰数据库。用未来和处理大量的类来处理工作负荷和数据集。

　　15.除非有可靠的工程理由，否则必须确保试验码达到100%的代码覆盖率。不能只是使代码演习空闲下来，要对逻辑结果进行真实测试（利用正检验和负检验的主张）。不要用无操作statement加入代码来人工增加统计覆盖率。