微服务架构实战-1-项目开发规范

编码和命名规范

1）变量 方法 类的命名风格统一 （全部驼峰）
2）团队开发要勤写注释
3）最好由组长定义一套增删改查 从controller层到service 到serviceImpl 到dao层到mapper 的编写规范（分布式项目中还包括 feign客户端 fallBack降级类 yml配置的模版规范） 大家按照模版来套 保证整个项目的风格统一 提升代码的可读性 便于项目代码维护
4）数据库表名 字段名 命名风格统一
5）每个表都必须包含 创建者的id 创建时间 修改时间 修改者的id 逻辑删除状态标志 isDeleted （0 未删除 1 已删除 该字段需要默认值 0）
6）前端参数结构统一 一般包含以下内容：
a)pageParam 分页参数 （包含 pageNum 页数 pageSize 每页数据量 orderParam 排序数组）
b)T 范型 存放实体类参数
7）一个模块正常情况应该提供以下功能接口：（第一个版本不要求加权限判断 正式版要给每个接口的访问加权限控制）
a)getOneById 根据id获取某个对象
b)existOneById 通过id判断该对象是否存在
c)existOneByCondition 通过对象的参数判断是否存在这样的对象
d)addOne 添加一个对象 并支持该对象字段的校验 前端后段都需要校验
e)addSome 添加一批对象 每个对象都要进行字段校验
f)deleteOneTrueById 通过id物理删除一个对象
g)deleteOneLogicalById 通过id逻辑删除一个对象
h)recoverOneById 恢复一个备逻辑删除的对象
i)deleteSomeByIds 通过id数组 删除一批对象
j)updateOne 根据id来条件修改一个对象
k)searchSomeByPage 条件 分页 排序 查询获取对象数组
l)superSearch 通过一个关键字 检索所有类型为字符串的表字段

git使用规范

1）在分布式项目中 组长负责模块的创建 组员需要创建新模块必须通知给组长 让组长来操作 建好后组长通知各个组员 去git仓库拉去最新代码
2）不允许随意删除他人创建的代码和模块 如果需要在组内及时沟通 确定好以后 再去实施 代码变更以后及时通知组员 去git仓库拉去最新代码
3）代码提交：提交前 先拉取仓库最新代码 有冲突解决冲突 解决完了之后才能提交代码（注意：只提交自己改过的代码 系统或者工具生成的配置其他文件不要提交 建议ctrl键 选中改动的代码右键提交 禁忌整个目录全部提交）再提交一些大家都需要频繁改动的代码时 一定要及时通知小组其他成员 及时拉取最新代码
4）每个成员最好单独开发自己的模块 不要去修改其他模块 如果确实需要修改 通知组长 讨论决定 改完后 第一时间通知组内成员拉取最新代码
5）项目中公共资源的处理 例如：common模块 父模块的pom文件 最好是由组长来改 或者争得组长同意以后 再去修改 完成后 还是第一时间通知其他成员拉取最新代码
6）idea创建的多模块项目 提交时千万注意不要勾选 idea开头的目录 这个是一些本地配置 每个人电脑上可能都不一样 提交上去会导致别人拉下来的项目不能运行

maven使用规范

1）在maven多模块项目中 尽量将其他子模块都要使用到的依赖统一放到父模块中管理 由父模块集中管理依赖和依赖的版本号 每个依赖都要写好注释
2）禁忌在common模块pom中引入依赖作为公共依赖来使用 common最好只是存放一些实体类和工具类
3）注意eureka-server依赖不要放在父模块的pom中 这个要在每个子模块中单独引入 因为gateway 的依赖和eureka-server依赖有冲突

数据库使用规范（可选）

1）使用mycat来管理mysql集群 比如 订单模块需要访问订单的数据库 那么组长在mycat中配置订单的逻辑库 并给组员分配一个订单逻辑库的可读可写的账号 同理每个组员负责什么模块 都给他分配一个该模块可读可写的账号 （最后在分配一个 可读所有逻辑库的账号 保证大家可以在navicat中可视化的查询数据）—避免大家越界操作数据