開發十年，就只剩下這套架構體系了！ >>>   

一、使用者介面

1、設計原則

1）對齊

• 層次結構清晰，觀察 1 畫素，引導視覺流向，讓使用者更流暢地接收資訊
• 如果頁面的欄位或段落較短、較散時，需要確定一個統一的視覺起點

2）多元化

• 根據不同的使用者體驗，可快速進行介面色調切換
• 點選側邊欄頭像，擴大工作區域顯示，可快速摺疊側邊欄和頂部導航欄
• 根據使用者喜好，可摺疊側邊欄，預設摺疊側邊欄，取消頁籤模式，表單彈窗模式
• 彈窗的表單，關閉表單後，自動重新整理列表資料，保留列表查詢條件
• 列表操作體驗清晰，不太實用的操作進行摺疊隱藏
• 列表查詢區域隱藏，擴大列表顯示區域

3）佈局色彩

• 響應式樣式，12 列柵格化佈局，根據螢幕大小進行自適應佈局，支援平板或手機操作
• 色彩源於『自然』的設計價值觀，設計師通過對自然場景的抽象捕捉

4）導航設計

• 在廣義上，任何告知使用者他在哪裡，他能去什麼地方以及如何到達那裡的方式，都可以稱之為導航
• 支援側邊欄全部導航；或者頂部一級導航，二級以下導航在側邊欄

2、資料列表

1）列對齊方式

• 短小字元居中，比較長的字元居左，日期居中，貨幣或帶小數點的數字居右
• 數值位數相等的欄位，如：編碼、編號：居中
• 字典類，如：分類、型別、類別、狀態：居中
• 不規則長度，5個字元以上，名稱、標題：居左
• 日期時間：居中
• 與貨幣相關的，金額、單價：居右
• 帶小數點的數字，數量、百分數：居右
• 整數型數字，年齡，個數：居中
• 合計，與合計列對齊方式相同

2）列顯示格式

• 與貨幣相關，金額或單價：保留兩位小數，如無特殊要求，不加貨幣符號，不使用千分位符號，預設單位“元”，如果單位不是“元”，則必須在列標題或當前頁標明單位，如：金額（萬元）
• 長字元列，名稱、標題、備註等：當列寬不足時，用 … 號表示無法顯示的字元
• 日期：yyyy-MM-dd，日期時間：yyyy-MM-dd HH:mm，如業務無特別要求，不帶秒，如需要時分秒，格式為： yyyy-MM-dd HH:mm:ss 採用24小時制
• 列寬要適中，根據內容調整列寬大小

3）其他要求

• 列表中存在與金額相關的列，或者與數量相關的列，根據業務要求，列表底部增加合計，如果列表是分頁列表，合計預設為查詢結果的合計，而不是當前頁合計
• 合計校驗：明細行合計值，與合計行值相同，不要出現明細與合計的數值不對的情況
• 彙總與明細校驗：彙總值與鑽取的明細合計值相同，同上
• 根據業務要求，比較大或比較耗時的頁面，第一次開啟時，如沒有特殊要求，預設不執行查詢顯示資料，需要點選查詢，執行顯示資料，並提示“點選查詢顯示資料”資訊
• 對於列與數字相關的，如：金額、數量、證件號碼（如：身份證）或其它由長數字組成的欄位，不能出現科學計數法格式
• 明細行中不能存在重複記錄

4）查詢條件

• 資料字典欄位作為查詢條件，無特殊要求，資訊內容相對固定少於20行時，採用下拉選擇方式，否則採用彈出對話方塊選擇方式；有特別要求時，可以採用輸入方式，進行模糊查詢，除此之外，必須採用選擇方式
• 查詢條件為多行時，標籤需要上下兩端對齊，標籤單行右對齊，注意美觀
• 輸入框或選擇框，上下兩端對齊，寬度適中

3、編輯表單

1）表單控制元件

• 必填資訊，必須明確區分，標籤前增加紅色星號，醒目顯示，必填資訊在儲存時必須增加必填驗證
• 數值型別，必須增加數值驗證
• 日期型別，必須增加日期格式驗證
• 邊界驗證，錄入資訊的長度不得多於資料庫欄位長度，input標籤必須包含增加maxlength屬性
• 無特殊情況，如：電話、身份證、郵箱，能用正則表示式驗證的欄位必須啟用驗證
• 介面錄入資訊與列表顯示資訊保持一致，避免欄位張冠李戴
• 介面顯示資訊與數字相關的，如：金額、數量、證件號碼（如：身份證）或其它由長數字組成的欄位，不能出現科學計數法格式
• 必須避擴音交型別按鈕多次執行，出現多條相同資訊，在未成功之前，不能多次點選

2）其它要求

• 對整個專案進行跨瀏覽器的測試（必須相容IE9+、360、Chrome、Firefox瀏覽器）
• 介面大小應該適合美學觀點，感覺協調舒適，能在有效的範圍內吸引使用者的注意力，注意細節（觀察1畫素距離、列表文字對齊）
• 必須保證在最小解析度1024x768的可視性（不允許錯版），在高解析度下頁面要自適應，不能出現標題背景空白，錯位情況
• 每一步操作，如儲存、更新、稽核，都要有提示，如：儲存xx成功！
• 檢查介面是否有文字錯誤，避免出現看不懂的文字
• 手機端或PC端圖示及標題內容顯示不全的，應儘量減少文字，不顯示…，讓文字顯示全

二、資料庫設計規範

1、命名規範

• 資料庫物件，如：表、列、索引、檢視、儲存過程、自定義函式，的命名的原則是簡、短，易懂好記，有意義的英文單詞、常用縮寫，多個單片語成的，當長度比較大時應使用縮寫，特殊情況使用拼音或首字母
• 資料表命名：必須帶有模組字首，如財務總賬：js_fin_
• 如果命名由多個詞彙組成，詞彙之間加 _ 下劃線，如：js_sys_office_company

2、設計規範

• 通常情況下每張表必須有主鍵，對於非主鍵，具有唯一性質的，必須加，唯一索引
• 每張表，每個欄位都必須有正確的中文描述說明，以便快速生成資料字典
• 業務資料表必要時冗餘基礎資訊表的核心欄位，如：部門編碼、部門名稱，需要成對出現在業務資料表中
• 對於字元型別（VERCHAR）欄位，確定資料值僅是數字、字母並無其它特殊字元的情況下使用VERCHAR欄位，其它必須使用NVARCHAR型別，避免使用VARCHAR型別
• 表字段的長度要統一，尤其基礎資料在業務資料中的引用，如：部門編碼、部門名稱，在任何業務資料表中的長度務必保持一致
• 儲存過程、自定義函式、檢視，以及排程，必須要有詳細的註釋說明
• 統一入口，統一出口原則：相同意義的資料儲存、提取，使用同一過程和方法
• 不要盲目的加入其他索引，根據需要統一加索引

3、使用規範

• 在指定使用者下，只有專案經理具有資料表物件的設計許可權，其他開發人員不得調整表結構
• 作業排程需要有詳細的登記臺賬（也是專案管理要求的一部分）
• SQL書寫採用：關鍵字大寫，表名，列名小寫
• 變更資料庫必須同步 erm 模型

三、平臺開發規範

1、JeeSite 包的命名規範

設有公司統一報名如：com.jeesite 包，不允許直接在此包下直接建立模組，要先建立一個 modules 包。

• 模組格式：com.jeesite.modules.模組名.分層.子模組名.功能類
  • 分層為 entity、dao、service、web、utils、config
  • 若模組下只有幾個功能，沒有子模組，就不需要再建立子模組了
• Spring Boot 自動配置檔案格式：com.jeesite.autoconfigure.模組名.配置類
  • 自動配置的類，在 META-INF/spring.factories 裡指定
• 通用封裝包或工具類：com.jeesite.common.大類.小類.封裝類

2、JeeSite 分層命名規範

Controller

四名保持命名聯絡： Controller類名、對映路徑、方法名、檢視檔名，舉例如下：

Service

Dao

Entity

3、JeeSite 檢視檔案規範

所有檢視檔案均放在：模組專案/src/main/resources/views 目錄下，儘量不放在web專案下，約束如下：

4、JeeSite 靜態檔案規範

所有靜態檔案均放在：模組專案/src/main/resources/static 目錄下，儘量不放在web專案下，約束如下：

四、其它開發規範

主鍵：有意義的，有規則的資料必須採用手動編碼方式，不允許使用 UUID 自動生成註解表示，方便運維，例如：組織機構