開發中的常見問題
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
一.不定義常量(constant),代碼中隨意使用數字,并且不加任何注釋
癥狀和例子: 判斷"chipType == 2" - 2是什么意思?為什么不定義一個常數 "REALMONEY = 2",然后使用這個常數? 惡劣后果: 旁人不知道該數字什么含義,時間一長包括自己在內都不知道其準確含義。代碼重構不可能(無法替換某個常數所有的出現之處、無法穩妥改動數值) 正確做法: 代碼中任何常數都必須被定義。不要隨手使用數字 二.代碼對一些僅用于標識事物種類的數值敏感(not agnostic to number value that represents type information) 癥狀和例子: 隨意指定一些值,以標識一些事物的不同種類。目前常常用來作為客戶端與服務器端的協議,各端往往需要對數值的含義作出分析,然后執行相應的動作。此外數值的指定非常隨意,無規律、無準則 惡劣后果: 代碼完全沒有robustness,一個數值的改變即可導致程序出錯 正確做法: 對于代表種類信息的數值、或者是代表個體的數值,或者稱之為"標識型"數值,程序應該盡量做到對具體數值不敏感。如果數值影響算法,那么應該明確數值生成的規則,有一定規律,而不是兩個開發人員私下協議"我給你個1你就應該做什么"(如果需要這樣的話,證明是協議需要設計) 三.不使用枚舉類型 癥狀和例子: 用一堆整數來代表一些事物的類別 惡劣后果: 因為不能做到type safe,很容易錯誤使用而不被檢測。如果寫代碼時cut and paste一些類似的賦值語句,則很容易把完全風馬牛不相及的值賦予給變量。此外一堆整數雖然都是為了標識一類物體的不同種,但這種關聯無法貫徹。此外定義一堆水果種類與定義一系列交通工具,彼此無本質區別,代碼編譯時都是整數 正確做法: 在Java中,應該使用Enum枚舉類型。在Actionscript中,沒有Enum的情況下,可以定義一個類,然后用這個類的實體(instance)作為標識,如: * 定義一個叫Fruit的類 * 構建多個Fruit實體,分別賦予多個全局變量(global、static),每個變量名為某種水果如: APPLE、ORANGE * 把上述對象當作常數使用 四.不支持國際化 癥狀和例子: 在代碼中寫死文字信息,比如簡體中文 惡劣后果: 網站和客戶端都需要i18n支持,一旦代碼中到處都是寫死的文字信息,非常難改變過來 正確做法: 現代IDE中對國際化、ResourceBundle等的支持已經非常好,需要做的事情就是學會使用 五.所有條件判別代碼擠在一個龐大的函數中 癥狀和例子: 所以if...then或者switch...case語句,把所有情況判斷后的處理代碼塞在一個地方 惡劣后果: 首先,這種做法讓代碼閱讀、檢查不舒服,太長太不好理解;其次,也是最主要的缺陷:完全沒有可擴展性。每次多一中情況的發生,就必須去改這個龐大的函數。雖然說改動也許可以只局限于一個函數,但實際上這個函數所在的類(文件)已經被修改,所以嚴格來說這個類及其一切相關代碼都需要被重新測試 正確做法: 使用Command pattern;或者最簡單是把對應某個條件的處理代碼抽離到獨立的類,把這個類更進一步抽象出通用接口。這樣每次有新的條件需要處理,我們可以增添新的處理邏輯到新的類里面,然后把這個類通過polymorphism傳遞給中央處理程序 六.參數寫死在代碼中 癥狀和例子: 最常見的問題是把URL寫死在代碼中,基于當前有限的理解,對系統和商業領域作了很多假設 惡劣后果: 導致代碼的兼容性極差,完全沒有portability。系統從一個環境挪到另一個環境,問題就會不斷出現 正確做法: 細心、不怕麻煩、抽象出可配置的參數,設計時考慮部署和運營的方便 該文章在 2010/8/13 18:24:44 編輯過 |
關鍵字查詢
相關文章
正在查詢... |