代碼優化

一、數據庫層面

1）在作批量操做時，先用一句SQL從數據庫中查詢列表數據，而後再內存中去遍歷，不要在循環中每次發起一個SQL請求；由於數據庫鏈接很耗性能

 

二、代碼層面

1）之後合併批量操做和單條操做，統一用strList來接受參數

2）爲避免多餘的拆箱和裝箱操做，之後前臺傳參統一使用strMap，不用objMap

3）寫代碼遵循一個原則，至繁歸於至簡

 

三、命名規則

1）方法命名不加of，關聯事務的命名仿照 updateAssessmentSubmit

2）關於列表展現的命名仿照 listFinalAssessmentPass

3）角色放後面，功能修飾放對象前面，仿照updateAssessmentBackKpb, updateAssessmentBackQt

4）原則遵循：對象放前面，動做修飾放後面

 

四、提示語句

修改叫填報，查詢叫提供

必須選擇一條記錄進行操做！

操做失敗，請聯繫管理員！

至少選擇一條記錄進行操做！

 

五、其餘

註釋不須要每一個地方都寫，要注意他存在的本質，像添加方法，咱們的提示信息已經一目瞭然了，就不須要寫註釋了，而查詢方法沒有中文提示信息，咱們就須要寫註釋。

別小看if else，這麼設計是有它的理由的，能用的時候就用上

代碼相關的部分放在一塊，這樣能夠很方便的抽取出來

若是前臺輸入沒影響個人程序運行，我能夠規避他，我就不報錯

儘可能寫一些公用性的提示信息，不然模塊之間粘貼複製太麻煩了

若是和用戶操做失誤無關的錯誤，在後臺的處理方法採用不提示錯誤信息，默默的讓這種操做失敗，好比報送、審覈這些操做，若是用戶經過平臺途徑操做，那麼他確定能成功，若是不能成功就是程序的問題或者別人經過非法途徑攻擊系統。

平臺自定義的strMap、modelMap必須是平臺本身實例化的，不要程序員本身去new

連綴表達式能夠在架構中用到

SQL語句須要美化

災難性檢測，例如此次的角色管理配置功能項時出現的BUG

在後臺，不管是什麼操做（例如批量添加等），都應該將各自的方法寫在各自的接口裏面，一切爲解耦考慮

應該按照規範英文命名

接口排序的方法按照頁面功能的排序

公用接口放在最後面

jhcnd改爲con

jhupdate改爲update