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

Last week, we covered how to evaluate code that is developed to extend cloud applications. Now we're going to take a look at coding and system modification strategies that can make the system more fragile over time. Since CRM systems have requirements that seem to evolve endlessly, durability of your code is a key factor to long-running success of these systems.

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

The tension between declarative development and programming

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

Cloud-based applications have a bias toward what the vendors call "declarative development," because it's unambiguous, easier to learn, and easier to control in a SaaS environment. Most cloud applications will make heavy use of validation rules on fields, constraints on fields and tables, and workflows on objects. This works fine in the early days, and it provides a surprising amount of power and functionality.

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

The trouble comes when you add code, particularly anything that creates new records. When developing that new trigger, class, or integration "listener" service, the coder may be working in a development or sandbox environment that isn't configured identically to the production system. When pushing the code to production, all kinds of error conditions are thrown -- and they may not be reproducible in the dev environment. Unfortunately, the error messages can be very ugly for users and may not even provide many clues for the troubleshooter.

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

The first set of tips:第一套建议：

1. Make sure that developers work in a recently refreshed "sandbox," so they aren't surprised by the configuration of the production environment.

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

2. To the degree possible, enable integration adaptors and other plug-ins in the sandbox, so that developers can see the ramifications of state changes (particularly the "reflection" of error conditions back from outside sources).

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

3. Once you start developing extensions and functionality around an object, remove all validation rules and reimplement them inside your low-level code so that you can predictably trap and control error conditions.

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

4. In a similar vein, replace any workflows that do field updates with low-level code implementations.

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

5. Create an administrative policy that makes it very difficult to create new validation rules or workflow-driven field updates.

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

6. Make sure you put code in to provide guardrails in front of field or table constraints, essentially pre-checking the values to ensure they don't hit any walls.

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

7. Check every field for NULL, and check every set, list, or map for EMPTY before you try to use it in any logic (yes, even any error-checking logic).

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

8. As mentioned in "Error Handling in the Clouds," write classes that handle all application errors in real time send them as messages to centralized error-logging services elsewhere in the cloud.

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

Table-driven, up to a point尽量让表格控制

Everyone knows that hard-coding values in the middle of a class or trigger is a bad idea, and everyone should be putting such parameters at least in static-final variables in the declarations section of each module. Even better, move those variables into a lookup table or resource file that is loaded on every run of the code.

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

Even though databases like to be normalized and nearly anything can be made into a lookup, it's quite easy to be overly abstract and generic. Excessive pointer-chasing leads to lowered understandability by anyone who wasn't the original developer, and it can slow the app down (or even push against a cloud environment's governor limits). So the next few tips:

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

9. Do put configuration parameters (such as pick-list values, allowable states, or configuration options) into lookup tables. Do include a comments column in each of these tables, with remarks that a human can read to understand the semantics, behavior, and update history of the table and values. If your cloud system supports it, keep this table in memory ("custom settings") versus on-disk for lower latency.

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

10. Do put these look-up tables under configuration control. At the very least, lock down the access and make sure that these tables are backed up regularly.

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

11. Don't be lazy with the table and field naming -- this is where sloppiness upfront costs you at troubleshooting time. (One example, of a table named "folly," comes to mind.)

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

The cloud demands agile, XP, or TDD coding styles云计算要求灵活，XP或TDD编码风格

I don't know of a cloud environment that actually precludes large modules, waterfall development, or excessive nesting/branching, which means, you'll find examples of those every once in a while. But once and for all, we need to jettison these styles in order to foster solid, lasting code.

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

12. Objects are not just for UI. They're there to support understandability, reuse, and refactoring. But don't go nuts; make sure your objects really do support understandability -- or none of the other benefits will occur.

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

13. Keep modules small, simple, and separable. Check out the KISSS Principle, which also leads to easier test and debug.

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

Don't bump up against platform limits 避免超越平台限制

Cloud platforms may impose governor limits for certain kinds of operations, such as database queries or in memory table-creates. When you first develop a bit of functionality, make sure that you aren't burning more than 50 percent of those maxima in your initial release. It won't be long before you have new requirements and fire drills that will mean you'll need even more of those resources.

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

14. Use in-memory caching of data ("bulkification" and "dynamic SQL") rather than hitting the database every time. Use future and batch classes to handle bulk workloads and data sets.

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

15. Make sure your test code gets to 100 percent code coverage unless there's a solid engineering reason why it can't. Perform real tests of logical outcomes (using asserts on positive and negative test cases), not just idle code exercises. And don't pad code with no-op statements to artificially drive up coverage statistics.

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

工作签证出国

深圳筹划税务收入

代理记账会计公司