酒店项目的心得体会

今年4月初参与了开课吧的真项目。项目的目标是作出一个订酒店的平台。

在此之前没有参与过任何真实项目，所以这次项目的参与感触颇多。

项目流程

从我加入这个项目开始（我加入的时间较晚），我把项目从开始到结束经历过的流程大概分了一下：

蓝色的是我参与过的部分。

1. 框架搭建

这个部分我虽然没有参与，但是也大致了解了一下这个项目所用到的框架，以及框架在项目中的作用。

以上是项目的流程图，由于我对上面的一些技术还没有详细的了解，我把我自己对这个流程图的大概理解描述一下：

客户端发送请求，请求经过DNS解析后通过防火墙等，进入Nginx集群，Nginx集群对请求进行负载均衡处理。将请求下放到合适的服务器，服务器内，由Spring Cloud Gateway来通过Ribbon负载均衡将请求分发到对应的微服务，如果微服务无法访问，则会使用Sentinel熔断降级直接返回结果。

每个微服务都被OpenFeign代理，以便于其它微服务调用。微服务内，查询数据库，返回信息给客户端。

除了请求会直接用到的框架，还有一些框架是与用户请求关系不大但是仍然是必要的。

例如Nacos对服务进行注册。还有Nacos实现动态配置（不需要重启服务器可以实时配置）。还有Skywalking进行链路追踪和监控报警。还有日志的搜集。一些数据库查询时用到的ES。Redis缓存。日志系统。等等。

总体来说，这个项目用到的技术非常之多，这也让我感觉到一个项目的上线是有多不容易，一个完整的项目需要如此庞大数量的技术支持（太卷了）。

2. 项目拆解

在框架搭建完成后，我们就进行了项目拆解，把项目拆解成不同模块，在对每个模块进行分工。每个人都写了一份自己对于项目的拆解文档，而我是用思维导图的形式展现的拆解：

现在看来，有点小乱，其实这一步的意义我自己到现在也没有特别理解，因为到后面好像并不需要我们拆解的这么仔细，在这一步只需要把模块划分出来就行了，拆出来也就7-8个模块。

最后我参与的是房型模块。

3. 数据库设计

我参与的是房型模块，所以也就是对房型模块进行数据库设计。

我们首先根据项目需求，拆解这个模块所需要从后台拉取的数据，以及数据类型。

再理清数据直接的关系，然后建表，这是我最后设计的数据库（不是最终版）

我自己对我的数据库设计还是比较满意的，我认为可维护性很高。后来组内也是在我的版本上修改，添加。

在数据库设计中，有一块是让我们讨论了最久的，就是餐食组合的设计。

我的想法是，餐食组合涉及到三个表，餐食组合表， 餐食组合餐食中间表，餐食表。这样的话后期增加新的餐食类型也方便，也便于维护。

组内有的成员觉得，酒店其实没有什么餐食，就是早餐，午餐，晚餐，根本不需要餐食组合，所以直接把早午晚作为三个字段增加到房型的表里就行了，都不用额外建表的。

他们说的这种确实会让整个数据库变得简单很多，进行api编写也会简单很多毕竟不涉及到联查。但我总觉得，世界是在变的，现在酒店没有这种餐食不代表以后就没有。如果数据库一开始把这个地方设计死了，后面一旦出现变数会很麻烦。

在方便和可维护上，我选择了可维护。最后小组也还是采用了我的想法，设计出了额外的3-4个表，用于表示餐食组合。

4. 接口设计

数据库设计完成后，紧接着就是接口设计了。

我们首先对房型模块进行评估，看看这个页面的加载，各个按钮的点击，都需要从后台调取哪些数据，然后把需要用到的接口都大概先列出来。

然后再对接口接收的参数，返回的数据进行设计。

这是我设计出的接口列表，大概就是这样子，但还有些缺陷，例如返回的格式，接受的参数，url的格式，都有问题。

url内的单词分隔符只能用-

参数的单词分隔符才用_

后来等所有人把自己的接口设计好之后，经过开会，师哥多次对我们的接口的错误进行纠正之后，我们组内再把每个人的接口进行整合。就出来了我们模块的所有接口的最终版本。

5. 代码编写

接口设计完成后，就对接口进行实现了。

说实话，这是耗时最久的，也是最麻烦的一部分。其实我本人一开始对代码没有什么特别的要求，我自己的理解是，代码精简，高效就好。我基本没有怎么考虑别人能不能读懂，还有格式的一些问题。

我负责的是：餐食组合的添加（也就是我在数据库上的要求，现在要我自己来实现），餐食的增删改查，房型筛选列表的显示

我没有存我之前代码长啥样，但是我自己心里能感觉得到，就可读性来说，经过师哥几次修正后的版本，代码好看很多，也更符合规范。

有几个点，是师哥开会后我才懂得要怎么写的：

1. mbp进行查询时条件不要用QueryWrapper，要用LambdaQueryWrapper

2. 代码中不要出现魔法值，例如状态码404独立出现这种。常用的一些值，或者是有意义的值，要包装成一个常量对象，然后直接调用对象的参数来获取这个值，不能直接在代码中写数字。

3. if语句内的条件，要提取出来，赋值给一个名字有意义的布尔值。

4. 继承了IService的Service有自带的CRUD方法，不需要自己编写。

5. 尽量多用.equals，少用==

6. 代码要有层次感

7. Controller层不能抛异常，异常都要到Service层抛

8. Controller层的业务逻辑要精简，最好不要有逻辑，代码越少越好，所有业务逻辑都放到Service层。

总的来说，这个项目对我代码质量提升有很大帮助，其他方面，例如逻辑啊什么的到没有太大的提升。

在代码编写的过程中，我也知道了很多优化查询效率的小技巧，例如用Redis缓存，优化SQL语句等等。

在最后看到自己的API能够返回所需的数据，并且处理任何异常状态，心里还是很高兴的。

6. 与前端对接

这一块其实参与的不多，但是我们把接口都提供给了前端，前端会进行调用然后把有问题的接口反馈给我们，我们会进行调优。不知道是不是我的接口目前还没出现问题的原因，目前还没有收到前端的反馈。

7. 上线

写这篇博客的时候，还没有看到项目上线，不过应该快了。

8. 收获

总的来说，这个项目对我来说最大的收获就是明白了一个项目从开始到结束需要经历的流程有哪些，另外，也让我了解到了项目需要用到的一些框架，我以后就可以往这方面去多学点知识。

师哥也发了一套质量非常高的面试题大全，我一直以为，国内的很多这种面试题教材，就是一堆枯燥的知识点，让你去死记硬背，直到我看了一下那个网站。我说实话，我被吸引到了，我觉得我以后会经常看，我觉得它是真的想让我理解这些知识，所以不管我以后找不找工作，我都会去经常看的。

我觉得，这次项目上，之所以我们能够编写的这么顺利。其实是因为有很多看不见的工作被别人完成了。那些框架，都已经搭建好了，对于我们写代码的人来说，就只需要调用就好。所以才会这么方便。但我更希望我自己是那位为别人创造方便的人，所以在框架上，我以后也会学这去搭建，把这个项目每个用到的框架都弄懂。我相信当我这一切都学会了以后，会非常开心。

路还很长，希望自己能继续怀着这份热情学下去！