【51CTO 10月26日外電頭條】上周，我們介紹了如何對用于擴展云應用程序的代碼進行評估?，F(xiàn)在，我們要將目光投向那些編碼及系統(tǒng)方面的改造策略，這些策略很可能隨著時間的推移使系統(tǒng)變得愈發(fā)脆弱。由于CRM系統(tǒng)那看似永無休止的發(fā)展需求，我們代碼的耐久度將成為能否長期順暢運行這些系統(tǒng)的關(guān)鍵因素。

但在開始之前，我需要聲明一點：我所舉出的使用實例及條款只適用于Salesforce.com環(huán)境；其它應用環(huán)境及平臺所使用的是不同類型的協(xié)議（甚至是不同的抽象結(jié)構(gòu)），鑒于我對那些內(nèi)容并不十分了解——因此請不要誤以為我是個玩命幫Salesforce.com造勢的五毛黨。

聲明式開發(fā)與編程之間的利弊關(guān)系

云計算基礎(chǔ)應用程序更偏愛供應商所說的“聲明式開發(fā)”，因為這種方式明確、易于學習且在SaaS環(huán)境下更易于控制。大多數(shù)云計算應用程序會帶來繁重的信息組驗證規(guī)則、信息組及列表約束以及對象方面的工作流程。過去這種方式頗為有效，因為它提供了數(shù)量驚人的處理能力及功能。

但當我們需要向其中添加新代碼，尤其是會創(chuàng)建新記錄的代碼時，麻煩就會隨之而來。在開發(fā)新的觸發(fā)器、類或者集成化“監(jiān)聽”服務時，編碼者很可能會在特定的開發(fā)環(huán)境或者沙箱環(huán)境中進行工作，而這些環(huán)境的配置很可能與生產(chǎn)系統(tǒng)本身并不匹配。當代碼被加入產(chǎn)品時，各種錯誤狀況往往層出不窮——而且通常無法在開發(fā)環(huán)境中進行返工。遺憾的是，錯誤信息不僅對用戶來說非常討厭，甚至還不能為故障排查提供足夠的線索。

***組提示：

1.確保開發(fā)工作在***更新的“沙箱”環(huán)境中完成，這樣開發(fā)人員就不會頭痛于其與生產(chǎn)環(huán)境之間的配置差異了。

2.在可能的情況下，在沙箱中***程度啟用集成適配器及其它插件，這樣一來開發(fā)人員就可以看到狀態(tài)變化（特別是從外部來源所‘映射’得出的錯誤狀態(tài)）所引起的后果。

3.一旦大家開始針對對象開發(fā)擴展及功能，務必刪除全部驗證規(guī)則并在低級代碼中重新加以實施，這樣我們才能預見可能出現(xiàn)的陷阱及控制誤差條件。

4.出于同樣的目的，大家要把任何將會引發(fā)信息組更新的工作流部署于低級代碼當中。

5.創(chuàng)建一套管理規(guī)則，并保證其難以創(chuàng)建新的驗證規(guī)則或是能引發(fā)信息組更新的工作流。

6.必須保證代碼能夠為信息組或是約束條件列表提供保護，對值的預檢查將幫助我們規(guī)避棘手的難題。

7.通過檢查確保每個信息組為NULL，并且每個集、列表或者映射都為空，之后大家才能嘗試在邏輯關(guān)系中加以使用（沒錯，甚至在一切錯誤檢查邏輯關(guān)系中也是如此）。

8.正如之前提到的“云計算中的錯誤處理”話題，為實時掌握所有應用程序錯誤編寫類，并將其作為消息發(fā)送至云計算中的集中式錯誤日志服務處。

盡可能以列表為核心

大家都知道，在類或觸發(fā)器當中對值進行硬編碼不是什么好主意，因此我們至少應該將這些參數(shù)部署于每個模塊的聲明區(qū)段中?；蛘吒M一步，將這些變量移動到查找列表或者資源文件之類每當代碼運行都會加載的部分里。

盡管數(shù)據(jù)庫越來越標準化，而且?guī)缀跻磺袃?nèi)容都可以被添加進查找列表當中，這種做法仍然有些過于抽象且寬泛。過度追求指針引導使得任何除原始開發(fā)者之外的人士很難理解，并且會造成應用程序運作緩慢（甚至會影響到云環(huán)境的調(diào)速器限制）。因此以下提示就變得非常重要：

9.務必將配置參數(shù)（例如選擇列表的賦值、獲許狀態(tài)或者配置選項等）添加至查找列表中。務必在每個查找列表中包含批注行，并保證他人能夠通過閱讀這些備注理解列表及值的語義、行為以及更新記錄。如果大家的云系統(tǒng)能夠支持，還應將該列表保存在內(nèi)存（‘自定義設(shè)置’）中，以避免由磁盤讀取帶來的高延遲。

10.務必將這些查找列表置于配置控制之下。至少要鎖定訪問行為，并確保此類列表得到定期備份。

11.不要懶于為列表及信息組命名——一時輕松往往會在故障排查中給你帶來巨大的麻煩。

云計算要求敏捷、XP或者TDD（即時分雙工）類型的編碼風格

我不太了解那種排除了大型模塊、瀑布式開發(fā)或者大量嵌套/分支化內(nèi)容的云環(huán)境是個什么樣子，不過大家應該偶爾會碰上這種實例。不過為了一勞永逸，我們必須拋棄這樣的做法，因為它完全不利于打造牢固、持久的代碼。

12.對象不只是針對UI。它們的存在是為了支持可理解性、重調(diào)用及代碼重構(gòu)。不過千萬別犯傻；對象對可理解性的支持是一切的前提——失去了可理解性，其它各種益處都將煙消云散。

13.保證模塊小巧、簡單且可分離。仔細閱讀KISSS原則，該原則同樣會使測試及調(diào)整工作更為輕松。

不要躁進，關(guān)注平臺的局限

云計算平臺會給特定類型的執(zhí)行內(nèi)容（例如數(shù)據(jù)庫查詢或者內(nèi)存內(nèi)列表創(chuàng)建等）帶來局限。因此如果大家是***次開發(fā)功能性產(chǎn)品，必須確保自己的***發(fā)行版本不能超過資源指標上限的50%。因為不久之前大家必然會面臨新的需求及應急手段，這些都會帶來更大的資源消耗量。

14.盡量使用內(nèi)存緩存中的數(shù)據(jù)（例如‘bulkification’以及‘動態(tài)SQL’），而不是每次都勞煩數(shù)據(jù)庫。多利用未來及成批的類來處理大量工作負載與數(shù)據(jù)集。

15.除非有什么硬性設(shè)計原因，否則必須確保我們的測試代碼獲得100%的代碼涵蓋率。不要只為閑置代碼搞演習，而應該對邏輯結(jié)果進行實際測試（通過正面及負面測試反復驗證）。另外，不要把無操作狀態(tài)填進代碼中，借以人為抬高統(tǒng)計數(shù)據(jù)的覆蓋率。

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