食堂管理项目总结

工具应用：

swagger

swagger很久之前就在本地的Spring boot练习中整合过了，从整合配置到接口测试都很熟练。但这次上来就无法访问接口，原因就是没有写入token令牌（之前学swagger时知道有授权这一说，但是这还是第一次用）。

控制台抓取token

这个虽然不是啥技术性问题，但讲真的之前一直是通过控制台上输入js命令获取的，这次才发现控制台可以直接获取

git

之前做项目用过git（可是一出问题就不是一下子能看博客解决的，都是身边人先口头提出解决方案，不行后再由别人亲自来摸索、解决，反正解决了也不知道为什么）。但是这次，从项目拉取到代码提交分支合并都熟练的掌握，最重要的是解决冲突，因为之前从未实践过。那些个git命令在过去是死记硬背的，而且有些还是搞混了，但这次在一次、两次、三次、…的看笔记操作之后，我终于可以熟练掌握，而且能够明白的辨识git命令执行后的代码状态。

git status
git add .
git commit -m "备注信息"
git push origin dev
git pull upstream develop
解决冲突(如果有冲突从第1/2步重新开始）
git push origin dev
git仓库merge

xiaopiu

这个原型图设计平台在之前就简单应用过，这次也是得以温习（但这次原型图设计我并没有着手参与）

YApi

这是一个制定APi文档的平台，在这里面学到了很多规范性的问题，同时也是第一次制定API文档，真真正正体验到了之前组长所说的“前期工作远多于写代码的时间（数据库阶段设计ER图时组长告诉我的话）”。

项目知识：

领域模型

在过去VO、PO、DTO等都是我一直在强记却不曾实践的东西，即使嘴里天天念叨着它们的作用，在项目中还是认为后端中只有实体类，前后端的数据传输也只能通过实体类。这次，我实实在在的了解并在项目中应用了它们，知道了它们各自的作用。

返回前端数据序列化

这个说法还是第一次听说，就是在返回前端的数据类中实现Serializable接口（其作用就是：直接以 Java 对象的形式进行保存，按照一定的格式将 Java 对象的某状态转成介质可接受的形式，以方便存储或传输，然后再重新得到该 Java 对象）。说白了就是数据传输中防止意外错误的一种机制。

uid

同样是返回前端的对象，serialVersionUID（起到一个标识作用确定是同一对象）也是一项必不可少的细节。

private static final long serialVersionUID = 3687474089085604431L;

当类实现了Serializable接口后，会自动生成uid。如果没有自动生成需要对idea进行如下设置：file→settings→Editor→Inspections

曾经忽略掉的命名规范

在项目开启之前我重新回顾了一下命名规范和restful接口风格，可当我接手项目时还是不敢下手。多亏组长鼓励和指点，经过一天的适应总算从容了一些。在这个过程中我发现曾经学习命名规范时忽略了领域模型的命名，即区域名+表明+大写包名后缀。最重要的，由于第一次参与后端，看着项目环境里面已有的命名风格总是和我所学的规范对不上号，请教完组长后终于悟了——在仿照已有的风格的同时尽可能的保持规范，懂了，要去适应项目。

接口规范

明白了什么是restful风格API。在过去一直到处去了解restful风格长么样，鬼知道就是我天天用的Post（@PostMapping）、Delete（@DeleteMapping）、Put（@PutMapping）、Get（@GetMapping），其特点就是通过一个访问URL的不同请求方式完成多项功能，在SpringBoot中的实现就是controller层的类上通过@RequestMapping注明访问URL，在类中具体的方法上注明请求方式。


如图就可以通过“/canteen/dishesInfo”这一个请求地址的不同请求方式实现不同功能。此时回想起来我学过swagger之后就一直写的restful风格API，而swagger其中一个特点就是restful风格。

安全认证

做这个项目之前从未应用过security，其实还是很不自信的，奈何项目中还就是用到了。好在这次的需求没那么困难，我也就做了一个用户认证，但从中也算大概明白了security是怎么一回事了。

    private boolean checkShopScope(Long shopId) {
        if (ObjectUtils.isEmpty(shopId)) {
            throw new BaseException("商铺id不能为空！");
        }
        // 从Security中获取用户的个人信息预留字段shopId，为0的话就是所有店铺的管理员
        SysUser user = SecurityUtils.getLoginUser().getUser();
        Long userShopId = user.getUserId();
        if (ObjectUtils.isEmpty(userShopId)) {
            throw new BaseException("当前用户没有操作店铺的权限，请更换账户后操作");
        }
        return userShopId.equals(shopId) || userShopId.equals(0L);
    }

mapper映射

不得不说这次mapper是我遇到的最大的问题。之前学习中青睐于注解开发，奈何这次技术选型用的mybatis，而且用的还是mapper.xml映射。原本一个@one、@many就能解决的东西，搞得我又是resultMap又是collection的，一个多表查询的sql也就一两分钟的事，可是换成mapper.xml真的要吐了。而且这次数据库表建的是真的不敢恭维，搞得我和我组长两个写后端的叫苦连连。但不得不说学到的东西确实不少，就比如说刚提到的collection，这可是我第一次在mapper.xml中使用。

<collection property="plateName" column="{dishesName=dishes_name,areaId=area_id,shopId=shop_id}" javaType="String" select="selectPlateIdByList"/>
<collection property="shopName" column="shop_id" javaType="String" select="selectShopNameByShopId"/>

看这两行代码，column属性就是一个我当时遇到的问题，单个参数直接写，多个参数必须用大括号。

参数验证

这个不得不说给我整的挺尴尬，因为这是我在关系表数据同步都完成了以后才发现的问题——我居然没做空参请求验证。然后我就想着速战速决赶紧加了个if判断

//判断参数是否满足要求
if("".equals(canteenAddDishesInfoParams.getDishesName())||canteenAddDishesInfoParams.getAreaId()==0||canteenAddDishesInfoParams.getDishesPrice()==0){
    throw new BaseException("请完善参数");
}

匆匆忙忙写完后才想起来 @Validated，我直接在要验证的参数上添加@Validated不就完了？

public AjaxResult add(@Validated @RequestBody CanteenAddDishesInfoParams canteenAddDishesInfoParams)

返回数据规范

这个意识我倒是一直都有，可毕竟是头一次写后端，开始以为要自己写什么枚举类返回状态码啥的，没想到项目拉下来后发现环境里已经有了
而且就连响应结果都是封装好的，从中也明白响应数据的格式——状态+信息+数据。

/**
 * 响应返回结果
 *
 * @param rows 影响行数
 * @return 操作结果
 */
protected AjaxResult toAjax(int rows) {
    return rows > 0 ? AjaxResult.success() : AjaxResult.error();
}

分页查询与字典

曾经我一直以为分页查询是一口气查出了所有，只是展示形式设为分页展示了（当然我明白查询原理，但是还是以为分页查询也是可以一口气获取所有数据的，比如我设置每页100000条，只要数据库满足条件的数据不大于100000不就行了？现在想想太片面了太单纯了）。尽管曾经也想过——如果分页查询就是获取所有数据后分页展示，那么这不应该是前端的一个概念吗，为什么这个名词会出现在数据库？可因为当时阶段学习等原因我并未探究。现在终于懂了，那前端在有些场景需要一口气展示所有满足条件的结果怎么办？那就需要后端去写字典全部查询了。

能力提升：

快速学习

由于这次技术选型限定的是若依框架，而这个框架之前从未接触，所以只能从头学习。也许是前期长时间学习的铺垫，这次若依框架的学习差不多也就花了一天时间，就简单跑通了所需部分的逻辑。

联调中团体合作意识

这次项目我负责了后端一半以上的接口（当然啊，多亏我的项目组长一个人搭建前后端环境并部署服务器我才能这么顺利），前期压力毋庸置疑，连着三四天不午休去加班。但是后期就有点无事可干的感觉，联调时我总有一种出不出bug无所谓，只要不是我负责的接口就行。直到两次联调结束我这边都没有明显bug，我开始飘了，说了句“哎！还好不是我的问题，哈哈”，这时候前端负责人也就随口说了句做项目不能有这种想法，说真的声音虽小但很震撼。这时才明白老师说的，做项目时要对项目有整体把握，不能觉得做完自己的就万事大吉。

项目流程的把握

此次项目中我了解到了一个完整项目的开端到收尾的大体流程，同时也了解到了我的项目组长做的那些工作（说真的，好多我都不会，可早晚有一天我也会成为项目组长的）。在整个项目流程中格外引起我注意的就是项目环境搭建，里面用到的服务器部署（Linux）、整合各种技术栈，还有加版本锁等细节问题多的让我震惊。

业务逻辑分析

这次项目对我来说不同以往，之前写前端也就是听组长安排，写什么页面、哪些功能，其他一概不管。而这次把整个项目需求理了一遍
从中也发现了许多需求不明了的地方提出了一些有价值的问题（因为后期我们都依次遇到了）。

联调测试

这次项目我参与了两次联调，形成问题文档一篇。这也是我第一次正式联调，从中也是学到了很多规范，比如测试数据每次最好是只设置一项问题数据等。