How to Avoid Cloud Code Breakage, Part 2

Cloud applications provide a variety of mechanisms for development and configuration. Some of them lead to more fragility than others.

1 2 Page 2
Page 2 of 2

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.

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 can slow the app down (or even push against a cloud environment's governor limits). So, the next few tips:

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") vs on-disk for lower latency.
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.
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.)

The Cloud Demands Agile, XP, or TDD Coding Styles

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, re-use, and refactoring. But don't go nuts: make sure your objects really do support understandability -- or none of the other benefits will occur.
13. Keep modules small, simple, and separable. Check out the KISSS Principle, which also leads to easier test and debug.

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% 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.

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.
15. Make sure your test code gets to 100% 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.

David Taber is the author of the new Prentice Hall book, "Salesforce.com Secrets of Success" and is the CEO of SalesLogistix, a certified Salesforce.com consultancy focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel, and India, and David has over 25 years experience in high tech, including 10 years at the VP level or above.

Follow everything from CIO.com on Twitter @CIOonline.

Copyright © 2011 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Discover what your peers are reading. Sign up for our FREE email newsletters today!