開發規範

　　代碼規範很重要，能夠提升代碼的可讀性、擴展性、美觀性，也能減小Bug出現率，即便出現也能夠很快定位問題，解決問題。

（一）代碼命名規範

1. 駝峯命名：類、結構體首字母大寫；方法、參數、變量首字母小寫；常量所有大寫；
2. 抽象類以Abstract開頭；枚舉類以Enum結尾；
3. 獲取數據以 get 爲前綴，例如：getData()；獲取多條數據以 List 爲結尾，例如：getAreaList()；插入使用insert爲前綴；修改以 update 爲前綴；刪除以 del 爲前綴；其餘方法命名儘可能體現業務實現

（二）註釋規範

1. 類註釋必需要有，而且每個類都以實現一個業務操做爲基準
2. 方法註釋要言簡意賅，通俗易懂，不要有太複雜的邏輯
3. 代碼註釋，儘可能在代碼塊前進行註釋，不要放到代碼行的後方
4. 接口註釋，必須有接口入參及出參說明

（三）HTML規範

1. HTML編寫，應當先肯定頁面接口，按照結構，由粗到細，逐步填充內容
2. 非必要，儘可能不要使用 position: absolute、float 等浮動佈局，若是確實有必要，建議指定父級的relative，不要在全局定位；float以後，要清除掉浮動，減小因瀏覽器版本致使的佈局變更
3. 代碼作好縮進，分級編寫，不要在一行內寫入多層結構

（四）JS規範

1. 不建議使用 function xxx(){} 這種方式直接建立方法，建議按照分類，建立方法對象 xxx = { aaa:functoin(){}, ...}；例如：加載方法寫在Init對象中，驗證方法寫在Vaile對象中，頁面邏輯寫在 Handle對象中 等
2. 若是頁面JS較多，建立以頁面命名的JS，頁面引用JS
3. 公共方法中，不使用具體的頁面控件對象，如必須使用，儘可能減小單個方法內操做的具體對象數量，不使用單個方法作太多邏輯處理，而是經過多個方法共同實現某一個功能
4. 多個公共方法組合實現某個功能時，組合方法不建議做爲公共方法，而是用到的地方本身組裝
5. 不能方法內部層層嵌套，原則上應該是 業務方法 -> 基礎公共方法，每一個頁面的業務方法都要單獨寫，哪怕邏輯相同，也要避免使用公用的業務方法
6. 不能再js中進行大量的Html拼接，若有必要，可將html作成部分視圖進行js引用處理

（五）樣式規範

1. 樣式也是與HTML相同，先寫全局樣式，再寫模塊樣式，最後寫特殊樣式
2. 樣式也要層層嵌套，不建議跳過父級模塊樣式，直接用ID寫樣式，很差控制；
3. 減小行內樣式，如想肯定某個樣式始終有效，避免被行內樣式覆蓋，在css中添加 !important
4. 母版頁的全局樣式，建議單獨css文件編寫，內容頁面樣式較少時，直接在頁面頂部構建頁面單獨的樣式

（六）數據庫規範

1. 表命名以 t 爲前綴；視圖以 v 爲前綴；存儲過程以 p 爲前綴；觸發器以 tri 爲前綴；
2. 表命名使用英文，所有小寫，單詞之間如下劃線「_」分隔
3. 表名和字段名儘可能簡短
4. 大長度字段，建議單獨表存儲，經過id管理
5. 字段過多時，作表橫向切割，能夠按照字段業務來劃分，例如 訂單提交信息；訂單流轉控制信息；訂單業務信息等；
6. 索引等信息避免大字段；
7. 寫修改或者刪除腳本時，先寫條件，在寫要修改或者刪除的語句；修改儘可能先查找出來id，經過惟一id進行修改
8. count() 和 count(xxx) 語句查詢結果是不一致的，前者是不去null，後者是去除null以後的數據
9. 當表較多時，建議按照業務，使用不一樣的數據庫用戶名（架構名），既方便查找，也方便進行管理

（七）異常規範

1. 要區分穩定代碼和非穩定代碼；不能使用try catch包裹全部代碼進行異常捕捉；
2. 不能try catch中嵌套try catch，只在非穩定代碼中加try catch
3. finally中不能使用return；
4. 捕捉異常以後，若吞沒該異常，儘可能作好日誌記錄
5. 若繼續拋出的異常將會脫離框架控制範圍，必須作result套接；例如接口，不能直接將異常拋給客戶或業務端，致使外部資源崩潰；
6. 對內業務，建議處理異常並拋出異常提示，對外代碼，建議以代碼Code標識異常類型
7. 避免一個異常，多處重複記錄

（八）接口規範

1. 接口返回必須有result包裹，不能直接返回data數據
2. 接口儘可能避免返回null，建議處理成空對象返回；若有須要返回null，須要在接口中註明，並提示接口調用方對返回值作校驗
3. 接口架構：可使用同一個對外接口，根據枚舉類型的不一樣Code進行，使用IOC分別映射到不一樣的接口實現類中，好處是能夠很方便的對接口請求作控制和驗證，代碼結構也比較整潔有序，後續新增或修改接口時，只須要改動相應的業務便可，無需考慮驗證問題

總結：

　　每次看到之前寫的代碼，都感受很渣，這是本身能寫出來的代碼？而後或者默默優化一下，或者直接忽視，等到問題爆發在進行打補丁式的查找修改。

　　寫這篇文章的目的也是對之前編程的一個回顧，即便到目前爲止，上述的不少規範也沒有作到，加以自勉吧！