代碼的價值不在本身大小和複雜度，而在於多少其他代碼在用它。
我們的一個產品依然有很多代碼採用了“點連接的長行代碼”，比如權限檢查代碼：
// 檢查當前用戶是否有對象搜索的權限
AppUtils.UserInfo.CheckLimit(CarpaServer.Common.OperatorLimit.LIMIT_OBJECT_HISTORY_SEARCH) ;
這樣的代碼，儘管只有一行，但是冗餘非常的多——每次都要重複的加入
AppUtils.UserInfo命名空間，CarpaServer.Common。如果不這樣，就會需要using ；也是很麻煩的。
單獨看這樣的一行代碼，很多人的反應是：這麼點的差別何必改它呢？雖然不爽，但是也不是多大的問題。可是放眼整個項目，可以想得見，類似的代碼必然大量出現。冗餘因此會被放大很多倍數。
我查詢了下這個產品的代碼，在編碼過程中（沒有完成項目代碼的時候）發現有990次使用。引用如此衆多，優化也就是必要的了。
實現一個屬性
Public static Limit.OBJECT_HISTORY_SEARCH
{
get{
return AppUtils.UserInfo.CheckLimit(CarpaServer.Common.OperatorLimit.LIMIT_OBJECT_HISTORY_SEARCH) ;
}
}
其他使用的地方只要這樣調用就行了：
Limit.OBJECT_HISTORY_SEARCH
不僅僅權限，還有配置類，也是到處都在用的代碼，比如:
代碼類型：配置,包括 SysData，SysData1，UserConfig
方法：AppUtils.CheckUserConfig("userconfig", "btypeall", "1") == "0"
新方法： public bool UserConfig.BtypeAll
在配置類代碼內，好處不僅僅是簡潔，還有後者沒有字符串的出現，都是強類型的代碼，也不必使用和字符串比較這麼低級的操作，用戶使用起來就更舒服。
配置代碼，權限代碼的特點是到處都在使用，一旦寫就，以後也就不好修改了——這也是分銷一直沒有動它的原因。因此，這樣的簡單封裝，一定要一開始就做對。幸運的是，這樣的事情一次做對並不困難。
代碼質量不僅僅影響閱讀效果，還會影響心情，對做編碼的程序員來說，心情成本是非常值得重視的。
