重作項目的初衷及計劃

公司最近作的管理系統，由於感受工做中系統框架設計很不合理，致使開發花費的週期也特別長，我跟組長有些設計理念不一樣，溝通無果，幾回差點吵起來。想一想程序員一句話叫「Talk is cheap,show me the code」因而想本身利用業餘時間把項目從新作一遍，也想借此機會鍛鍊和檢驗下本身獨立完成項目的能力。

首先總結下我認爲目前系統裏幾個主要的比較失敗的地方：

1. 權限系統：權限系統是我認爲此次工做項目裏設計最不合理的地方，由於有特殊需求，要對每一個項目的每一個模塊分開受權管理，相似於ACL，現有的RBAC模型不能知足。組長本身寫了套權限系統，基本上大體原理就是寫一個接口，把各類判斷權限做爲一個方法，而後針對每一個子模塊寫判斷，寫一個ModelAttribute方法，攔截全部的Controller，取查詢參數上的項目ID，而後去數據庫裏查詢對應項目的的權限，前臺用c:if標籤判斷權限。我認爲主要缺點是1，嚴重耦合，與模塊管理還有流程管理不少地方都是耦合在一塊兒的，且各個控制器裏要加一大堆方法。 2，依賴參數，由於ModelAttribute的方法是攔截控制器中全部方法，權限系統寫好後，咱們又花了不少時間改造Controller和前臺頁面。3，代碼臃腫，調試困難，每一個都單獨有個權限類，權限方法是寫死在子類裏的，寫起來很麻煩，並且前臺調試權限的時候要倒後臺跟斷點。4，多餘的開發，以前我提出過把項目角色集成到系統角色裏，被否決，這樣就等於要多寫一套管理入口。
    
2. 模型設計：太拘泥於三範式，表分級太多，表個數減小了，可是開發難度成倍增加。
    
3. 項目模塊：模塊都是在代碼裏硬編碼，包括模塊的結構，連接等，修改起來很麻煩。
    
4. 流程管理：流程管理，沒使用工做流或者設計模式，與權限系統耦合嚴重，致使要加很多邏輯判斷，每一個Controller裏還要加方法。
    
5. 代碼生成器：jeesite自己帶的代碼生成器功能相對而言不夠強大，在實際開發中也沒有充分利用起來。
    
6. 需求管理：我認爲開發系統前期須要跟用戶大量溝通，摸清楚用戶實際需求，此次項目開發的角色分工，到項目結束纔拿到，跟以前的表格不同。

基於以上幾點，個人新設計理念以下

1. 儘量避免重複造輪子，造輪子須要較好的基礎跟設計模式，且調試開發週期長，容易本身給本身挖坑。儘量簡化設計，一樣的功能，可能有幾種方案可行，多考慮幾種，儘量早的選定簡單的方案。應用設計模式，減小耦合，遵循單一職責原則，對擴展開放對修改關閉。最後，儘量最大化利用好代碼生成器。
    
2. 基於以上，我先選定的框架是Jeeplus，本身花120買了個無工做流的版本，開始看中的是他的樣式，可是試用了下發現他的代碼生成器很方便，比jeesite改良的地方是數據庫校驗和自定義對象查詢，很實用的功能。
    
3. 權限系統：初版方案我考慮用須要路徑中加入projectId來判斷，這樣的話就不用去管參數問題了，可是這樣仍然要用ModuleAttribute，且無法用代碼生成器，須要手寫不少東西，並且可能有個重大的弊端是由於是兩部驗證，可能致使權限轉移，一下沒想好怎麼解決。第二版方案是考慮用AOP，在須要權限過濾的方法前加入判斷。弊端跟前面同樣在前段應用不方便。第三種方案仍是用shiro，應該上是理論上最好的辦法了，可是如何針對單一資源，開始還沒想好，後來通過考慮跟試驗，發現權限字符串自己能夠支持，只要設計好怎麼加入變量進行判斷及如何受權。這種方法一旦把設計思路理順了，絕對是最方便開發跟移植的方案。
    
4. 模型設計：打算在必定程度上保留冗餘字段，違反三範式裏的第三條:好比此次的概算表，底下要分8個明細，這8個明細裏除了基礎屬性外，還有幾個價格字段，若是嚴格按照三範式的話，價格作成子表。如今實際開發過程當中以爲不合理，若是隻保留主表跟明細表，就能夠直接用代碼生成器，且簡化了查詢方法。也少了不少邏輯判斷。上個項目跟組長也有過相似爭執，他把報告的年限單獨拆出來作成父表。這樣報告就變成了項目->項目年限->報告三層數據，這樣在查詢，傳遞，邏輯判斷等等方面都增長了困難。我認爲年限做爲報告的屬性就能夠了，減小的開發難度是最少也是乘法級的。
    
5. 模塊頁面：打算單獨作一個模塊管理，模塊分兩類，主模塊，至關於分組，沒有直接的頁面，子模塊，實體的模塊，有頁面顏色圖標等屬性。這樣，就方便管理和持久化，能夠隨時在web端更換圖標連接等不用改代碼。載入模塊的時候，根據權限判斷具體哪些能展現，哪些隱藏起來。須要在開發中進一步思考跟解決的是，模塊如何跟角色掛鉤，角色如何跟用戶掛鉤，項目如何給用戶受權。這每一步都存在不少可能性，設計不當會成倍增長設計難度。 最開始模塊管理我打算應用最近學過的組合模式，可是發現沒有必要，本身已經可以方便的遍歷出來了，增長模式反而增長開發難度。
    
6. 流程管理：由於權限系統剝離出來了，流程也相對減小了開發難度。決定用狀態模式來實現，以減小代碼中的大量if else之類的邏輯判斷，分離出來也方便擴展。另外原有系統內的流程設計我雖然沒詳細看（也看不懂別人寫的代碼），可是從數據庫中觀察分析認爲，沒有必要把審批意見單獨分表---設計的時候不知道基於什麼樣的考慮，審覈跟意見是一對多的，多是由於其中有個動做是隻填寫意見，不審批？我認爲一個審批動做對應一條日誌，且一條審批動做有一個意見就好。估計是用普通邏輯很差實現，這樣的話，狀態機的好處就體現出來了，跳轉到本身原本狀態也能夠看作一個動做，把審批流程按順序記錄下來就好。
    
7. 代碼生成器：由於選的框架好，且更改了些模型設計，概算表我預計一天內就能夠開發出來（原來我用了至少一個禮拜，且後期花費大量時間修改樣式跟調試）
    
8. 報表系統：這裏指的是概算表，我打算用觀察者模式來解耦。
    
9. 其餘：原有項目用的是本身開發的上傳下載系統，我用的很少，我打算拿項目自帶的來實現，之前沒接觸過文件上傳下載，可能要踩坑。

不許備完成的模塊及功能有：

• 項目之外的模塊，普通增刪改查，項目預算表，大致上與概算表相同。
• 報表總覽與導出：目前項目裏用的普通文件預覽是pot與docx4j，在樣式上都不是很好。項目報表用的是ureport2，比較佔內存，將來會留意有沒有更好的工具。
• 上傳下載持久化及加密：感受把文件名保存在數據庫沒什麼意義，加密也沒意義，由於key是保存到服務器上的，若是拿到服務器權限，祕鑰也能拿到，解密也不成問題，畫蛇添足，且不方便之後遷移。
• 數據廢棄：功能上不復雜，就是加個標記而已，且沒什麼太多可改進的地方。
• 項目計劃任務：沒接觸這個模塊，直覺上感受也是體力活，架構上可優化的地方很少。

將來可待學習改進的地方：

• 工做流：狀態機雖好，也存在一些問題，如，不能配置，不能解決一些複雜問題。嘗試將來項目裏儘可能用activiti，或者本身嘗試下別的模式。
• springboot：打算再多嘗試一些框架，好比分模塊的springboot，好比支持restful先後端分離的框架例如guns
• 在線excel編輯：看能不能找到一個相似於vaddin-spreadsheet的框架，本項目中不少功能其實就是帶公司的excel表格標記，這個框架效果極好綁定方便，可是缺點太笨重了，先後端都帶的框架，且無法分離出來前端單獨配合springmvc使用。
• 其餘設計模式。此次也算第一次在實戰項目裏用設計模式，雖然之前跟着書敲出來大概明白，實際用起來仍是有很多問題，但願將來多在項目中運用。