0.一切以設計書爲準
在項目開工之前，需要撰寫一份詳細具體的開發設計書，每個頁面一個設計書，並且有通用部分的設計書，在設計書完全確定後再進行項目的開發，後期修改功能如果需要修改設計書，需要和客戶確認後先修改設計書再調整代碼。
設計書具有 修改履歷，頁面佈局，每個功能的數據流，詳細數據流，用戶權限表，CRUD圖，數據庫更新表，數據庫讀取表，修改部分用紅色標示，具體到每一個點。
1.Thymeleaf 數據顯示
取代html或jsp，使用Thymeleaf
2.配置文件配置用戶權限
設置查詢最大值
比如說設置5個用戶權限的編號，然後在數據庫中設置每一個用戶的編號，來進行權限的校驗
3.業務執行的日誌記錄
在配置文件中加入數據庫的記錄，每個數據庫操作進行記錄，並呈現在開發者console上
4.通用數據庫語句放在數據庫表，分類獲取
大批量的語句存放在數據庫，動態存取進行CRUD
5.多語言通過配置文件
配置文件可以更改系統的語言
6.多配置文件設置測試端，開發端及客戶端
多個配置文件比如說: dev1, dev2, dev3 配置多個數據庫，測試用，開發用等
7.跳轉路徑由一個接口負責
跳轉路徑通過一個接口，調用各自具體接口實現類的類跳轉方法
8.設置每個頁面每個功能的編號，輸入輸出編號依據編號創建
每個類都有獨自的編號，譬如大功能PSV001，小功能PSV001S01
同樣的，每個頁面按照編號進行命名
類編號唯一，分工明確，後期出現問題可以根據編號快速定位
9.提交表單與輸入輸出Bean解藕，使用深拷貝傳遞數據
創建的數據結構並不唯一，每一個頁面的每一個功能都有兩個bean
一個InputBean，另一個outputBean；
每個頁面的每一個Form表單都有一個Bean，
首先後臺通過Controller取得表單Bean，再製作對應service的InputBean，
service返回的outputBean再進行使用，避免操作表單Bean，數據解藕
10.大層分爲Common, Controller, Model, Repository
此處列舉一下常用的項目結構
Common -> Aspect
-> Bean
-> Exception
Controller -> Bean
-> Web
-> Utils
Model -> Bean
-> Service
-> Utils
Repository -> Bean
-> Dao
-> Utils
首先Common是項目通用到的一些Bean，Filter等，具體是放一些全局類的東西；
Controller是控制器，存放接收方法，表單Bean
Model存放service服務，以及輸入輸出Bean
Repository存放數據庫層，對應數據庫結構Bean，以及DAO
四層從上到下是由淺入深的關係
11.Repository層的數據庫DAO分爲Repository, Reposity Custom, Reposity Impl(實現)
具體是進行數據庫操作，分爲原生JPA（findById等），自定義Custom，以及Custom繼承類具體的實現
12.所有表單繼承BaseForm, 定義基本畫面id等
所有的表單Form都有自己的編號，繼承自Base，並且，每一個畫面具有ID，用於通用頁面跳轉
13.所有控制器繼承BaseController
BaseController實現一個接口，其中包括所有跳轉路徑，統一管理
14.所有服務繼承一個AbstractService，其中可寫通用服務
15.每一個Service的輸入輸出遵循編號
16.文件下載設置編號，統一管理
17.檢驗的全部寫在一起
對於表單校驗，有一個通用的必須輸入校驗，對每個input輸入框加入class來區分，在通用方法判斷class並進行各自的校驗，比如數位校驗、日期校驗等，也有每一個頁面有獨立的個別校驗。當然前後臺都需要校驗，js端存在校驗，後臺java端也存在校驗
18.zebra-dialog通用對話框
對話框使用該插件
19.Jasper出力文件自定義
文件通過數據自動生成使用該插件
20.測試的流程
首先測試者拿到項目，按頁面進行分工測試，首先單元測試（開發者），然後黑盒測試（功能測試），再進行白盒測試（代碼測試），整理bug彙總；
開發者拿到bug列表，進行修改，提交測試，測試者校驗通過，驗收者進行再次檢查；
如果驗收不通過，還原至測試者，判斷是測試問題還是開發問題，提交相關測試或開發。
21.其他
在項目管理中，review是非常重要的，在每個單元模塊開發完成後，需要由負責人進行代碼檢查，判斷是否符合編碼規範，比如所有的if有沒有分行，類有沒有編號，命名是否採用大功能-小功能的方式等等；