简单的附几张图

 在设计API接口时的一部分注意事项

1.请求的方式一般使用GET/POST

2.请求路径接口文档为准，与代码对应controller层一致

3.GET 请求的参数在 Query 里面填写，POST 在 Body 里写。不要混用

4.不要使用 RESTFul 的路径传参

5.参数名采用驼峰命名

6.数据库中存在的字段的参数，命名要保持一致，参数描述简单

7.如果参数中用多个 id 参数，必须区分命名，且要与数据库一致

8.响应数据示例的格式必须依据实际的格式

9.响应数据的类型和描述和请求参数的要求一致

总体的开发需求

由于第一阶段与第二阶段的代码实现主要区别是代码的优化，在基于mybatisplus开发上，更多的利用了本身分装的方法，使代码更加简洁。基础的房间号的增删改查就不再赘述。

需要注意的是：

全文不要写两表或多表联查，尽量单独的用独立的service封装，联查时调用多个service即可，然后用java的流来拼起来，因为

1. 单表走索引好保证，很难保证联合查询走索引，所以不见得联查会有多快
2. 系统拆分的话联合索引很难判断

2.返回值使用 CommomResult 分页 CommomResult<CommonPage>， 返回码 使用 resultCode

3.配置 redisTemlate 解决 redis 乱码问题

4.log、mpaop 切面 ：log 包提供 各个 controller 的切面处理,主要是记录请求信息。mpaop 提供 在portal 和 admin添加切入点，主要记录一些集合使用的时候出现异常的记录

5.调用Asserts.fail 会抛出 ApiException异常，被 GlobalExceptionHandler 全局异常处理器（处理GlobalExceptionHandler 里面对应的异常），@NotNull 注解也会抛出异常被 ControllerAdvice 捕获

6.redisServiceImpl 对 redisTemlate 的方法进一步封装。提供redis 的各项基本操作。

7.service 里面调用方法要加 this 来调用，直接继承IService。

8.DAO,VO注意大写

额外还添加了有关用户签到的接口实现，在签到接口的实现，选择采用redis的方式，可以使用Redis中的Bitmaps这一个数据集合。

需要注意的是：

1. Bitmaps并不是实际的数据类型，而是定义在String类型上的一个面向字节操作的集合。因为字符串是二进制安全的块，他们的最大长度是512M，最适合设置成2^32个不同字节。
2. Bitmaps的位操作分为两类：
   1. 固定时间的单个位操作，比如把String的某个位设置为0或者1，或者获取某个位上的值
   2. 对于一组位的操作，对给定的bit范围内，统计设定值为1的数目(比如人口统计)
3. Bitmaps最大的优势就是在存储数据时可以极大的节省空间，比如在一个项目中采用自增长的id来标识用户，就可以仅用512M的内存来记录40亿用户的信息(比如用户是否希望收到新的通知，用1和0标识)

简单来说bitmaps就是一个长度可变的bit数组。每个位只能存储0或1。就可以通过bitmaps的数据表示用户是否登录。索引的列就可以采用userId即可。

总结 

这一个多月的开发时光过得蛮快，其实总体的开发周期并不长，但好在经历了一整个开发的流程，慢慢了解软件开发的全过程，从需求设计，数据库设计，接口设计、熟悉版本控制工具的使用，说到这，对于git的使用也更加的得心应手，代码编写阶段与代码review，期间的很多次小组会议，共同学习阿里开发规约等团队协作。对未来的工作也有了相对更为全面深刻的认知。

期间也遇到不少的问题：

1. git的使用，之前没有怎么参与过大型项目的开发，git的使用频率也不是很经常，从自己的团队分支pull到整体的开发分支，也遇到过不少的代码冲突，代码的提交与更新都有更深的认识。
2. 在做需求分析的时候，使用的是ProgressOn这种在线画图工具来梳理酒店项目的具体流程。对项目中的模块就行拆分，比如用户中心，商家中心，酒店中心，后台管理员中心。涉及到es的搜索筛选，redis的应用等等，学习过程中最重要的是学习到整体的逻辑思维顺序。
3. 数据库设计的过程中，对不少字段都进行了修改，字段是否重复，是否符合阿里的规范，都是需要考虑的范畴，还有字段的冗余，设计中间表，创建合适的索引等等，在数据库设计的过程中，也温习了相关数据库的知识，用索引就要关注索引失效的情况，比如使用了select * 、索引列上有计算、用了函数、不满足最左匹配、like左边包含%、使用OR关键字、NOT IN和NOT EXISTS等
4. 接口设计那块，用的是apipost，相对于之前使用的postman来讲，中文界面对我这种初学者会更加的友好，前后端的交互也能简单直接的表现出来，当路径的功能名过长时，中间采用“-”连接而非下划线。
5. 具体的代码设计，由于使用的时mp，对于代码的整体整洁性的要求，我摒弃了之前相对冗余的写法，去学习了lambda的各种用法，学会了一些基础用法时发现确实简洁了不少，也没有损失很多的可读性。学会了一些条件构造器的使用，这些就要求了我对SQL语句的熟悉，使用stream流将实体类数据赋值，比如在传输中用的DTO赋值，就会经常用到Stream流。
6. 微服务和中间件的使用还是相对欠缺，由于负责的接口并没有直接的对接使用MQ，ES，后期也是详细看了别的模块同学使用的方式，也学会了一些，在实际应用中有了一点的头绪。

下面附一张我在学习mysql的知识点图

最后希望自己能够继续奋发向上，保持初心吧。