1倡缠、編程規(guī)范
本篇規(guī)范基于阿里巴巴哨免、華為的開發(fā)手冊，在此之上進行歸納整理昙沦，歡迎共同改進該規(guī)范琢唾。
1.1、命名規(guī)范
命名的關鍵是能準確達意 盾饮，減少不必要的英文縮寫采桃，拼音簡寫
- 項目命名：全部小寫，多個單詞以中劃線分隔丘损；
- 類命名：駝峰命名普办，首字母大寫；
- 方法命名：駝峰命名徘钥；
- 變量命名：局部變量采取駝峰命名衔蹲，全局及常量全部大寫，多個單詞以下劃線分隔吏饿；
1.2踪危、縮進規(guī)范
使用兩個空格蔬浙、或一個tab鍵進行縮進 。
1.3贞远、方法傳參規(guī)范
一個方法參數不超過3個參數畴博，超過3個需要構建javabean實體進行傳輸。
1.4蓝仲、注釋規(guī)范
- TODO/FIXME：用來描述待改進和已知缺陷俱病，格式應保持一致
// TODO @auther: 處理xx
// FIXME @auther: xx缺陷
- 類注釋需要包含作者、時間袱结、和描述信息
/**
* @auther admin
* @date 2022-04-22 14:05:00
* @description 集合工具類
*/
public class CollectionUtils{
}
- 方法注釋需要簡述方法作用亮隙，參數、返回值
/**
* 通過登錄token獲取用戶
* @param token 登錄后返回的token
* @return Principal 返回登錄后的完整用戶信息
*/
public Principal getPrincipal(String token) {
}
- 代碼間禁止使用尾注釋垢夹，對于復雜邏輯需要做分隔
public void login(LoginDto dto) {
/*-------------------------1溢吻、token是否存在--------------------------*/
do something
/*-------------------------2、token有效性驗證------------------------*/
do something
/*-------------------------3果元、tokens刷新----------------------------*/
do something
}
2促王、MVC規(guī)范
2.1、整體分層
- controller 層
- service 層
- mapper 層
2.2而晒、controller規(guī)范
- requestMapping應寫在方法上蝇狼，方法上的mapping可以一次取出；
- 正例：
@RestController
public class UserController {
@GetMapping("/api/user/list")
public R<List<UserrVO>> list() {
return userService.list();
}
}
- 反例：
@RestController
@RequestMapping("/api/user")
public class UserController {
@GetMapping("/list")
public R<List<UserrVO>> list() {
return userService.list();
}
}
- 使用restful進行api構建倡怎，增刪改查對應的方法操作為post迅耘、delete、put监署、get颤专；
- controller層不應出現主體邏輯，只處理參數檢驗焦匈、請求的分發(fā)血公、委派和結果響應。
2.3缓熟、service規(guī)范
- 過于龐大的service需要進行拆分累魔，按照功能職責進行區(qū)分，例如：UserService中與登錄用戶相關的部分可以拆分為處理登錄用戶業(yè)務的LoginUserService和用于用戶管理的UserService够滑；
- service應該具有較好的邏輯分層垦写，理想情況下對于產品只進行迭代，對于客開只進行拓展彰触，在功能研發(fā)時需要對技術方案進行評審梯投，防止相關邏輯界限不明、過分耦合；
- 使用聲明式事務 @Transaction時 需要指定rollbackFor分蓖，聲明事務的方法調用另一個事務方法時尔艇，啟動類需要開啟@EnableAspectJAutoProxy(exposeProxy = true)，同時方法內使用代理類使事務生效
UserService userService = (UserService)AopContext.currentProxy();
2.4么鹤、mapper規(guī)范
- 查詢中不建議使用 * 代替所有字段查詢
- 3表及以上關聯查詢需要在xml中編寫
- 不建議使用注解型sql
- sql中禁止使用寫死的常量作為條件
3终娃、表設計規(guī)范
良好的邏輯設計和物理設計是高性能的基石，應該根據系統將要執(zhí)行的查詢語句來設計schema蒸甜。
3.1棠耕、基本類型選取
- 時間類型：yyyyMMddHHmmss 時間存儲使用datetime，如果只是 HHmmss 使用time存儲柠新；
- 主鍵：使用數值型列作為主鍵窍荧，不建議使用字符型列；
- 字符型：可空長度不確定場景使用可變長的varchar進行存儲 恨憎，不為空長度固定使用char進行存儲蕊退。
3.2、表命名
命名全部小寫憔恳，以下劃線 _ 進行分隔咕痛，使用兩表名連接表示兩表間關系。
//用戶表
create table sys_user();
//角色表
create table sys_role();
//用戶角色表
create table sys_user_role();
3.3喇嘱、枚舉
使用枚舉類表字段注釋需要將所有枚舉含義進行注釋。
3.4塞栅、索引建立
- 普通索引：不使用物理外鍵構建表間關系者铜，通過查詢時建立的普通索引構建邏輯關系；
- 唯一索引：具有唯一性的列構建唯一索引放椰，減少邏輯代碼作烟；
- 聯合索引：對于多個業(yè)務場景下經常使用的多條件查詢構建聯合索引，最左列離散度最高砾医；
3.5拿撩、范式和反范式
- 范式操作多建立于寫多的場景，
- 反范式操作（冗余設計）多建立于讀多的場景如蚜。
3.6压恒、優(yōu)化
- 設計表時區(qū)分記錄表與關系表，關系型的表可以多使用緩存進行查詢優(yōu)化
