# microservices-backend

**Repository Path**: ubuntu-maxfeng/microservices-backend

## Basic Information

- **Project Name**: microservices-backend
- **Description**: microservices-backend
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 2
- **Created**: 2022-03-12
- **Last Updated**: 2022-03-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 规范建议

## 思维建议
在编码前建议思考使用最佳的方式实现业务，而不是实现最快的方式

## 工具设置
- 设置导包规则（禁止导入*） Settings-Java-CodeStyle
- 在idea中安装google java format 插件
- 设置git

## 工程结构 
```
├── backend-base        业务标准库，包含api协议定义｜鉴权规范
├── backend-dao         数据库访问层
├── backend-dto         数据传输协议层
├── backend-model       模型层
├── backend-proxy       代理层，置于web前面一层，可在这里实现鉴权/指标统计/流量限制
├── backend-web1        web层
└── backend-web2
```

## Bean规范建议
- 属性全部使用Java包装类型
- 使用lombok简化get/set
- Bean必须实现java.io.Serializable接口
- 所有的关于时间的字段类型统一为java.util.LocalDateTime
- Bean必须划分类型，可分为Pojo/Dto/Bo/Vo，一个Bean只能用在一种场景下，严禁复用
- Bean属性检验建议利用JSR303规范


## URL设计/web控制器规范建议
- 一个控制器必须代表一个对原子化的资源的CRUD入口
- 一个控制器必须有一个顶级路由，代表当前资源
- 严格遵守Http动词的含义 GET/POST/DELETE/PUT，切勿在URL随意发明Http动词
- 每个控制器里面的断点必须有两个对象，自定义Request和Response
- 如果Http动词远远不能满足业务代码的表达力，建议规范化标准动词
- 建议URL风格遵循Restful
- GET方法对应的方法名称建议以describe开头
- Post方法对应的方法名称建议以create开头
- Delete方法对应的方法名称建议以delete开头
- Put方法对应的方法名称建议以modify开头
- 遵循URL资源设计规范，推荐阅读谷歌云API设计规范文档：https://cloud.google.com/apis/design/custom_methods


## URL中的标准动词建议
- batchDelete
- cancel
- search
- move
- batchGet

以上仅仅是建议，在业务中遇到不满足需求的情况下可以和团队内伙伴协商增加自定义动词

## dao层标准动词建议
- delete
- update
- insert
- query

## service层标准动词建议
- describe 查询
- batchDescribe 批量查询
- delete 删除
- modify 更新
- create 新增

## service层规范建议
- 如果方法返回的是一个集合，应该必须保证不能返回为空，可以是Collection.emptyList()或者其他
- 如果方法返回的是一个对象，建议返回值为Optional
- service层多用于编写业务调度，建议代码长度不要超过80行，超过80行则需要继续考虑如果简化代码
- 在进行编写业务的时候，应当时刻保持对NPE错误，AOO错误保持警惕之心

## GIT建议
- 一个代码仓库应该至少拥有一个受保护的分支（master）
- 每个团队成员在开发过程中应当从master分支拷贝出一个新分支
- 每个新分支的代码在测试完成后建议压缩commit为1个
- 在新分支代码合并到master分支之前，应该需要团队内进行CodeReview，如果存在瑕疵需要更正，保证你的代码越写越好