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

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

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

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

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

***組提示：

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

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

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

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

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

6.必須保證代碼能夠?yàn)樾畔⒔M或是約束條件列表提供保護(hù)，對值的預(yù)檢查將幫助我們規(guī)避棘手的難題。

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

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

盡可能以列表為核心

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

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

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

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

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

云計(jì)算要求敏捷、XP或者TDD（即時(shí)分雙工）類型的編碼風(fēng)格

我不太了解那種排除了大型模塊、瀑布式開發(fā)或者大量嵌套/分支化內(nèi)容的云環(huán)境是個(gè)什么樣子，不過大家應(yīng)該偶爾會(huì)碰上這種實(shí)例。不過為了一勞永逸，我們必須拋棄這樣的做法，因?yàn)樗耆焕诖蛟炖喂?、持久的代碼。

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

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

不要躁進(jìn)，關(guān)注平臺(tái)的局限

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

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

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

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