這一次的畢業設計由於老師催的太緊，系統設計階段草草進行導致最終的編碼階段代碼復用率不高，辣雞代碼太多。同時還有就是自己的經驗不足，設計階段考慮的東西不夠多，拘泥於各種七七八八的圖中間，不能自拔，好了，廢話說道這裡，零零散散的總結一點心得。 （1）設計階段實體需要明確。 當一個系統需求分析階段過了以後 ...
這一次的畢業設計由於老師催的太緊，系統設計階段草草進行導致最終的編碼階段代碼復用率不高，辣雞代碼太多。同時還有就是自己的經驗不足，設計階段考慮的東西不夠多，拘泥於各種七七八八的圖中間，不能自拔，好了，廢話說道這裡，零零散散的總結一點心得。
（1）設計階段實體需要明確。
當一個系統需求分析階段過了以後，系統的功能、單位應該都已經比較明確。此時系統設計階段就應該明確系統需要哪些實體，也可以理解成有哪些的DO。
（2）代碼的分層需要清晰
這一次畢業設計將Service層的操作很多放到了Controller裡面，這樣是不對的，Controller用於轉發請求，向Service請求數據，不負責具體業務邏輯的處理，具體的處理應該放到Serivce中實現並返回。同時Service操作Dao層，Dao層查詢出來的數據的相關操作也不應該放到Service層裡面 ，每一層的代碼職責分清了才能夠更好的進行代碼結構的調整和復用，不會出現同一個操作同一段代碼出現在不同的文件裡面的情況。
（3）Dao操作
設計階段要明確以後將要對資料庫進行怎麼樣的操作，需要通過什麼樣的形式來到後臺拿數據。比如拿同一個類，但是傳的參數的數量不同，此時應該用到方法的重載，而不是通過命名不同的方法來進行區分，方法的重載可以提高代碼的清晰度，同時也便於他人閱讀代碼。
在資料庫語句配置時對於同一類型的操作應該採用動態Sql語句來進行動態生成，而不是因為一個很小的，比如查詢條件的原因而增加很多的重覆的代碼，這些都是在設計階段可以明確且在編碼階段可以明確避免的。
（4）方法的定義
對於Controller和Service中的具體代碼也許可以通過開發階段而看情況而定，但是數據操作部分的代碼應該是可以通過系統設計階段來確定方法的數量和職能的。
公共的操作工具方法應該放在相應的Util類中作為靜態的方法來調用。
除Controller意外，Service，Dao應該採用介面編程的方式來進行，不能隨意更改其中的方法，方法的調用應該全部通過介面來進行調用。防止有關人員操作到介面以外的方法，同時不應該暴露在外的方法和屬性應該通過Protect或者Private首碼來進行標識。
未完，待續。
