緒論
月底公司就要放假了所以這幾天無心工作，畢竟領導也不會安排什麼緊急的開發任務。所以就找了一件自己最喜歡做的事情：優化代碼。由於OA項目是自己在做，所以只要邏輯正確，即使修改一些代碼也不會給整個系統帶來麻煩，而且還可以使代碼邏輯清晰，複用率更高一些。在修改過程中，引起了自己的一些思考，所以記錄一下，分享給大家。
思考
1、表結構設計上的一些思考
在最初開始開發的時候，並沒有做更多的思考，一個審批流程只有兩張表，一張保存申請單信息（包括當前審批狀態），另一張存儲審批過程中每級審批結果。但是當我寫第三個審批流程的時候，發現每張申請單中會存在一些相似的信息，比如：是否提交、是否通過、審批是否結束、退回次數、下一審批人等等。每次新建申請單對應的表時都要加上這些字段，感覺麻煩的要死，所以就把這些字段單獨處理成爲一張表（狀態表）。在代碼中專門寫一個方法，當頁面第一次提交申請單時，後臺會在狀態表中新增一條數據並返回主鍵保存到申請單對應的表中，瞬間感覺減少了我很多的工作量。
以前看到過一片文章，說是當我們查詢數據時，字段越少，效率越高。更新時，修改的字段越少，效率越高。儘量把動態數據和靜態數據進行分離。這裏靜態數據就是申請表，當提交申請後，這裏數據就不允許進行修改，最多在退回的情況可以再次修改。動態數據當然就是狀態表了，在整個審批過程中這裏的數據會經常變化，所以單獨處理會非常好。
2、程序設計上的一些思考
這幾年在開發過程中基本使用的都是MVC這種方式。整個流程下來是：
視圖界面 → 控制層 → service層 → dao層 → 數據庫。
當年在東軟曾用過下面這種：
視圖界面 → 控制層 → service1層 → service2層 → dao層 → 數據庫。
有一段時間真的不太明白爲何要這樣寫，後來逐漸就明白了。
舉個例子說明一下：在做採購審批過程中包括項目採購和固定資產採購（都存在一張表中，用一個字段區分，兩個審批流程不同），當領導審批時候可能在PC端也可能在移動端，所以控制層這裏其實是有兩個，所以我在service1層裏面新寫方法，用於判斷申請單的類型，可以調用service2層中不同的審批流程。在前期設計中，service2層中對於不同來源（PC、APP）的審批是分開處理的，只是返回內容不同，這就造成了大量代碼的重複，還有就是當審批流程調整時，我改了對應PC端的方法，對應APP的忘了，或者修改不一致，都會出現一些問題，所以後期又進行了整合，無論來源，都會走相同的方法，只在返回值上做出特殊處理，減少了很大一部分代碼。
所以在service上分層，可以處理更復雜的業務，可能當時東軟也是在這個基礎上進行設計的吧。
剛開始使用IDEA這款開發工具時候有些不太適應，尤其喜歡重複代碼提示這個功能，可以讓自己思考這部分代碼是否能提煉優化。
作爲一枚程序員，我們就是在不斷的挖坑和填坑的過程中鋪平前進的道路。
以上思考都是仁者見仁智者見智，也許過個幾個月，我學到一些新東西，感覺這些優化也不是太好，所以僅供參考，不必當真。
（若有什麼錯誤，請留言指正，3Q）