一編程規約
（一）命名風格
某些時候在命名常量的時候，會覺得太長而減少長度導致命名不清。
抽象類及測試類寫得比較少。
這一點值得注意，在開發中，布爾變量我都是使用is開始。
關於包名和類名的單數和複數形式，主要集中在util這裏，有時候傻傻分不清楚。看到公司很多項目的幫助類包名都爲com.xxx.utils.
有時候嫌變量太長，會搞一些縮寫。
開發中不會在接口裏定義變量。但會在接口的方法裏訪問修飾符，公司很多代碼接口裏都有訪問修飾符。
領域模型命名命名基本上沒有按照阿里巴巴的規約，當然阿里巴巴也註明了這只是參考，而不是強制。與數據庫打交道的數據對象，多半在com.xxx.model包下，命名比較隨意，沒有加上DO後輟。
一個WEB工程的數據類通常分爲三大類：
持久類 包括與數據每張表完全對應的實體類（屬性與表字段一一對應），包括實體接收查詢結果類（屬性與表字段部份對應，比如只需要一個表的部份字段，比如多表聯合查詢，將多張表的字段組合成一個實體類，以便於接收查詢結果）。統一以DO結尾。
響應類 以DTO結尾。如果是JSP可能會直接傳回一個實體對象，如果是AJAX的話，直接會加一個json數組。
業務類 比如純粹傳參，包括從控制類傳到業務類，控制類接受前端參數類等。比如臨時數據傳輸類，包括從數據庫中得到一個列表，需要二次排序，使用一個實體來中間轉換。 統一以VO結尾。
（二）常量定義
有時候一個值只在代碼中出現1次，會偷懶不去定義變量。
這個問題偶爾會犯。
開發中常量會是一個類，但是裏面會根據業務分成許多內部類。
（三）代碼格式
這個平時開發中不會出現這種情況，但沒有形成嚴格的禁令。
這個值得注意，開發中確實在犯這種錯誤。
關於開發中一行代碼過長的換行，一般比較隨意，比如縮進
sb.appeng("zi").appeng("xin")...
.append("huang")...//爲了美觀，多半以對齊換行，沒有以四個字符換行
而且並於什麼時候換行，是以120個爲臨界點，但有時候是以當前編輯器顯示大小來權衡，並沒有嚴格執行。
這個沒有形成禁令，有時候能做到，有時候忘記。
（三）OOP規約
這點做得不是很好。
對Integer類型，我都會使用intValue來進行比較。
1),2)沒有問題，3）並沒有注意。不過這也只是推薦。
這塊做得不好。
這條只是推薦。
這條也只是推薦。但是自己在開發過程中對於修飾符的使用相對比較隨意。值得思考 。
（七）控制語句
剛開始寫Java時有炫技的心態，喜歡這樣寫，後來就不會了。不過scala表示不服。
開發中會這樣去做，但也要權衡具體情況。
這一點也要權衡具體情況吧，”複雜的語句“，怎樣纔算是複雜呢？
（八）註釋規約
方法，類基本都能做到，但類屬性上有時候做得不好。確實，在別處調用時，如果看不到註釋會非常不方便。同理，常量類，枚舉等也應該使用/***/註釋，而不是//.
二異常日誌
（二）日誌規約
五MySQL數據庫
（一）建表規約
一是字段命名，一是數據類型
數據庫表字段名使用駝峯命名。
對於一些表習慣使用聯合主表，摒棄自增主鍵。
（二）索引規約
通過只在需要通過索引執行查詢，使用insert into on dumpcate key update語法時纔會去創建唯一索引。可以使用唯一索引做一些數據校驗。
前輟索引的缺點是不能進行group by 和order by.
對於mysql來說，limit是個好東西。前提是表數據量在千萬級以內，一旦超過這個值，性能急劇下降。很多時候，都要想到這一點。
所有SQL語句都應該使用explain看下執行結果，進行優化。
（四）ORM映射
很多時候爲了方便習慣直接使用集合類做爲返回類型。
一般情況下都是使用#{},某些特殊情況下也只能使用${}