【51CTO 10月26日外電頭條】上周，我們介紹了如何對用于擴展云應用程序的代碼進行評估。現在，我們要將目光投向那些編碼及系統方面的改造策略，這些策略很可能隨著時間的推移使系統變得愈發脆弱。由于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%的代碼涵蓋率。不要只為閑置代碼搞演習，而應該對邏輯結果進行實際測試（通過正面及負面測試反復驗證）。另外，不要把無操作狀態填進代碼中，借以人為抬高統計數據的覆蓋率。

原文鏈接：
http://www.infoworld.com/d/cloud-computing/how-head-coding-errors-in-the-cloud-176632?page=0,0