如何避免雲計算的編碼錯誤 十五招教你搞定

上周，我們介紹了如何對用於擴展雲應用程式的代碼進行評估。 現在，我們要將目光投向那些編碼及系統方面的改造策略，這些策略很可能隨著時間的推移使系統變得愈發脆弱。 由於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

(責任編輯：蒙遺善)