開發建議

1.控制器

1.1.統一返回值（統一返回值不是指全部接口返回一樣的置，而是每一類（具體分類能夠更具業務須要或者其餘的方式）控制器只返會相同的JavaBean）。
避免方法簽名的改動減小返工量；數據結構肯定先後端數據處理減小溝通成本；返回結果一致表明可使用aop處理。

1.2.無特殊需求都須要有返回值
在1.1的前提下，實現1.2則減小前端重複修改的成本；後期拓展性更強。

1.3.避免出現業務無關的入參，變量，校驗等
無關入參（國際化參數，分頁參數，token等），非當前業務變量等會干擾控制器處理邏輯，不管是編碼實現時仍是問題定位時都不利於業務邏輯的理解；參數校驗和和其餘公共數據校驗會增長大量代碼，不利於具體業務邏輯的整理，實現，定位和排錯。業務無關的入參，變量等均可以經過ThreadLocal處理；校驗則能夠經過aop的方式統一處理。

1.4.出現json字符串入參或當參數超過三個時則須要定義Bean接收
json字符串的入參可讀性極差，並且難以校驗數據的正確性；參數過多的時候會影響調用者使用；定義Bean接收參數能夠增長可讀性，對調用者來講只須要關注參數Bean，而不須要關心順序減小出錯的可能性。

1.5.對於crud的控制器必定考慮權限和返回結果
crud的權限（示例僅供參考，具體業務有差別）新增，修改和刪除提供個數據全部者，查詢提供給全部用戶；對於crud的返回（示例僅供參考，具體業務有差別）：新增返回ID，刪除返回對象，修改返回ID和對象，查詢返回列表或具體對象

1.6.定義統一的異常處理器，用於友好的向用戶表達系統臨時出現問題。

2.接口（通常是service和dao）

2.1.同1.1

2.2.禁止透傳控制器返回值
若是接口將控制器的數據直接返回那麼表明接口直接處理完成一個業務，這樣違背分層（MVC）的初衷，也不利於接口被複用。

2.3.禁止出現json，map這類入參和返回值
json，map這類入參和返回值不論在哪裏都缺少可讀性並且不能強制約束和校驗必須約定一個規則（規則沒有約束性），沒有Bean有效和安全。

2.4.不容許出現Request，Response這些對象
緣由是，控制器應該處理這類數據，若是接口有這些對象，那麼接口實現類就必須是爲特定的一個或一類請求提供的不利於複用和業務拆分。

2.5.日誌容許出如今service和controller
主要的日誌應該在service,controller不能做爲主體，大量日誌應該放在aop中

2.6.使用aop處理異常打印日誌（接口和控制器都適用）
aop處理異常時分兩類：已知和未知，分別打印日誌，重點關注未知異常；aop打印日誌能夠收集請求時長等信息，便於後期找性能瓶頸。

2.7.定義業務異常（繼承RuntimeException而不是Exception），減小異常捕獲和空判斷
減小異常的捕獲，大部分異常都向外層拋有意義的自定義業務已常（若是異常時已知的時候）；減小空判斷，在須要判空的時候拋異常（除了用戶提交的數據），由於空判斷會讓系統執行正常（即便出錯了）。出現異常以後的處理應該是經過某種途徑告知開發者，記錄日誌，方便開發者及時知道問題並經過日誌快速定位問題。

3.日誌

日誌的做用大部分是用於查找定位問題（bug）的，同時須要提供必定的量性數據支撐後面的性能分析。日誌應該作到如下幾點：

• 問題出如今那裏（若是時分佈式的則肯定問題出如今那些機器設置某一臺機器）
• 出現問題時正在處理那些數據（用戶提交的數據，系統庫裏面的數據等）
• 在那一步出錯了（查詢DB出錯，封裝返回出錯等）
• 重要方法執行時長
• 重要處理過程執行時長
• 性能消耗大的步驟執行時長

要作到上述三點則要求日誌作到以下幾點：

• 新增，修改和刪除必須有日誌
• 出現分支打日誌，而且記錄一些重要數據（例如：決定分支走向的數據等）
• 重要方法必定要經過aop打上日誌記錄處理過程當中的重要步驟以及處理時長
• 重要的處理過程也須要打上日誌記錄每一個過程產生的數據並處理時長
• 已知的可能致使性能問題的處理過程須要打上日誌

4.工具類

4.1.具體業務代碼減小第三方類庫的使用，第三方類庫儘可能使用自定義工具類實現
使用工具類封裝第三方類庫能夠很方便的遷移，防止第三方類庫的變動升級致使業務代碼的大量重構

4.2.工具類儘可能使用父類型
例如：操做ArrayList<E>時工具類入參應該是List或Collection。這樣工具類更加通用

4.3.儘可能使用重載減小方法的記憶；實現代碼複用（嵌套調用）