【实训项目】校园物资报修管理系统——实训总结与个人收获一、前言这是这个系列的第三篇博文也是最后一篇。前两篇分别介绍了项目的环境搭建和后端核心功能实现这篇来做个整体总结聊聊整个实训过程中遇到的难点、解决思路还有我的个人收获。作为小组的数据库/后端工程师我主要负责数据库设计与ER图、接口需求梳理、后端公共模块开发、演示流程梳理这些工作。整个实训做下来虽然时间不长但收获还是挺多的。其实一开始听说要做实训项目的时候我心里还是挺没底的。因为之前上课都是学零散的知识点每个知识点都是单独学的从来没有把它们串起来做一个完整的项目。而且还是小组合作我也担心自己拖后腿。但真正做下来发现虽然遇到了很多问题但一步一步解决的过程中自己也在慢慢成长。从最开始连Spring Boot项目怎么创建都要搜半天到最后能独立完成一个模块的开发这个进步还是挺明显的。写这篇总结也是想把这段时间的经历记录下来既是对自己的一个复盘也希望能给正在做类似项目的同学一点参考。如果你也在做课程设计或者实训项目遇到了类似的问题希望这篇文章能帮到你。二、实训整体总结2.1 项目完成情况我们小组这次做的是校园物资报修管理系统从需求分析到最终完成大概用了两周左右的时间。系统主要包含四大模块用户管理、物资管理、报修工单、物资申请支持管理员、学生、维修人员、老师四种角色。为什么选这个题目呢其实也是因为我们平时在学校里经常遇到物资坏了报修麻烦的情况。比如教室里的投影仪坏了要找老师、找后勤来回折腾好几天才能修好这样不仅效率低下还引起很多麻烦。如果有一个线上的报修系统学生直接在网上提交申请维修人员就能看到效率肯定会高很多。技术栈方面后端用的是Spring Boot MyBatis-Plus MySQL前端用的是HTMLCSSJavaScript前后端分离开发。整体来说核心功能都实现了基本满足了实训的要求。当然作为一个学生实训项目肯定还有很多不完善的地方。比如界面比较简单功能也比较基础和真正的商用系统比起来还差得远。但对我们来说能把学到的知识用起来做出一个能跑通的完整项目就已经很有意义了。2.2 我的工作内容作为数据库/后端工程师我主要做了这些工作第一数据库设计。这是我最开始做的工作也是整个项目的基础。我先梳理了系统的实体和关系画了ER图然后设计了四张核心表用户表、物资表、报修工单表、物资申请表。表结构设计的时候考虑了字段类型、索引、约束这些尽量做到合理规范。说起来简单做起来其实花了不少时间。一开始我设计的表特别简单用户表就只有id、用户名、密码三个字段。后来和前端同学沟通发现页面上要展示真实姓名、角色、手机号、状态这些信息又回去加字段。来来回回改了三四版才最终定下来。现在回头看数据库设计真的是项目的地基。地基打牢了后面盖房子就快地基没打好后面盖着盖着就会出问题。第二接口需求梳理。数据库设计完之后我和前端同学一起梳理了需要哪些接口每个接口的请求方式、参数、返回值是什么。整理了一份接口文档前后端照着这个来开发联调的时候就顺利多了。这部分工作虽然不是写代码但我觉得挺重要的。以前总觉得写代码才是正事文档什么的都是浪费时间。这次才发现接口文档写清楚了前后端各干各的最后合到一起的时候基本没什么大问题反而节省了时间。第三后端公共模块开发。比如统一返回结果封装、跨域配置这些都是项目一开始就要搭好的基础。这些东西虽然不是业务功能但对后面的开发影响很大搭好了后面写业务代码就很顺畅。我记得当时搭统一返回结果的时候一开始是每个接口自己返回不同的东西有的直接返回对象有的返回字符串乱得很。后来觉得太乱了我就去查了查怎么封装统一返回结果写了个Result类。改完之后所有接口都返回Result前端处理起来也方便多了。第四后端业务功能开发。主要是用户管理、物资管理、工单管理这些模块的后端接口包括增删改查和一些业务逻辑。写业务代码的过程中我对三层架构的理解也更深了。以前只是知道Controller、Service、Mapper这三层但为什么要这么分每层具体干什么其实不太清楚。这次自己写了一遍才明白分层的好处职责清晰出了问题知道去哪一层找以后要改也方便。第五演示流程梳理。项目做完之后我还梳理了演示的流程从登录开始到各个功能的演示顺序确保演示的时候能把系统的核心功能都展示出来。2.3 小组成员配合我们小组一共五个人分工还是比较明确的。大家配合得还不错有问题一起讨论遇到bug一起排查。虽然中间也有过意见不一致的时候但最后都能商量出解决方案。团队合作就是这样每个人都有自己的想法有分歧很正常。关键是要好好沟通站在对方的角度想一想找到一个大家都能接受的方案。还有就是代码合并的时候一开始我们都是互相发文件你拷给我我拷给你特别麻烦还经常覆盖别人的代码。但后来我们改正了比如每个人负责不同的模块尽量不要改同一个文件提交代码前先拉取最新的有冲突及时解决。总的来说我们小组的氛围还是很好的大家都很认真也很愿意帮忙。谁遇到问题了喊一声其他人都会过来一起看。能和这样的队友一起做项目我觉得挺幸运的。三、项目难点与解决思路整个实训过程中遇到了不少问题有些是环境搭建的坑有些是开发中的技术难点。这里挑几个印象深的说说前两篇博文里提到的也一起总结一下。3.1 环境搭建类难点MySQL 8.0的各种坑这是最开始就遇到的问题也是踩坑最多的地方。第一个是驱动类名MySQL 8.0的驱动类名和5.7的不一样一开始照搬5.7的配置启动一直报错。我记得当时启动项目控制台报了一大片红看得我头都大了。仔细看错误信息说是无法加载驱动类。我反复检查了pom.xml里的依赖版本是对的啊怎么会找不到呢后来去网上搜才知道MySQL 8.0的驱动类名变了不是以前的了。就这一个MySQL的问题折腾了我快一个下午。现在想想其实都是很基础的问题但因为不熟悉就卡了很久。所以说环境搭建虽然不是什么高深的技术但也很重要环境搭不好后面根本没法开发。解决思路遇到报错先看错误信息然后去网上搜基本上这些常见问题都有解决方案。后来我专门把MySQL 8.0和5.7的区别记了一下避免以后再踩同样的坑。Maven依赖下载慢这个也是很多人都会遇到的问题默认的Maven中央仓库在国内访问很慢经常下载超时。我记得第一次创建Spring Boot项目的时候Maven下载依赖下载了快半个小时还经常失败重试了好几次才成功。当时我就想这也太慢了每次创建新项目都要等这么久吗后来也是讨论了一下然后搜索可以配置阿里云镜像下载速度会快很多。在settings.xml里加上了阿里云的mirror配置再下载的时候速度真的快了好多基本上几秒钟就下完了。解决思路配置阿里云镜像。在settings.xml里加上阿里云的mirror配置下载速度直接快好几倍。这个虽然不是技术难点但很影响效率早配置早省心。端口号被占用启动报错Web server failed to start. Port 8080 was already in use启动的时候报错看到8080我就感觉到肯定是端口号出现问题了本来想抱着试试的心态改一下端口号发现可以正常启动了。**解决思路**要么关掉占用的程序要么改配置换个端口。我个人认为换个端口号更加方便也不用考虑其他。3.2 数据库设计类难点表结构设计的合理性这是我遇到的第一个真正意义上的难点。以前上课都是照着题目写SQL真正自己设计表的时候才发现没那么简单。比如用户表到底要哪些字段字段类型选什么要不要加索引外键要不要加这些都要考虑。一开始我设计的表很简单用户表就id、用户名、密码三个字段工单表也就id、标题、内容几个字段。后来做着做着发现缺字段比如用户需要真实姓名、角色、手机号工单需要报修人、维修人员、状态、创建时间又回去加来来回回改了好几次。还有外键的问题一开始我给所有关联的表都加了物理外键结果删数据的时候特别麻烦经常因为外键约束删不掉。后来才知道很多项目里都不用物理外键而是用逻辑外键也就是只在代码层面维护关联关系数据库层面不加外键约束。这样删数据方便性能也更好。解决思路先把需求理清楚把所有实体和属性都列出来然后再设计表。设计完之后和小组同学一起讨论看看有没有遗漏的有没有不合理的地方。还有就是多参考一下成熟项目的表结构学习一下别人是怎么设计的。另外外键这个东西开发阶段其实可以不用物理外键用逻辑外键就行不然删数据的时候很麻烦还影响性能。这个也是我后来才知道的。实体类和数据库字段的映射问题实体类用的是驼峰命名数据库用的是下划线命名一开始查出来的数据有些字段是null找了半天才发现是映射的问题。我记得当时做用户登录功能查出来的用户对象username和password都有值但realName、createTime这些字段都是null。我反复检查SQL字段名是对的啊怎么会查不出来呢后来仔细对比了一下才发现数据库里的字段是real_name、create_time而实体类里是realName、createTime。原来是驼峰命名和下划线的映射问题。我以为MyBatis-Plus会自动处理这个后来才知道虽然MyBatis-Plus默认开启了驼峰命名自动映射但如果是自己写XML的话有时候会不生效。后来我在application.yml里显式配置了一下就正常了。解决思路MyBatis-Plus默认是开启驼峰命名自动映射的但如果是自己写XML的话要注意配置一下或者用resultMap手动映射。后来我在application.yml里配置了一下就正常了。3.3 后端开发类难点跨域问题前后端分离开发前端和后端端口不一样浏览器的同源策略会阻止请求也就是跨域问题。一开始前端调接口一直报错还以为是接口写错了后来才知道是跨域的问题。我记得当时前端同学说接口调不通我还说不可能啊我用Postman测都是好的。然后我们一起看浏览器的控制台发现报了一个CORS的错误。我当时还不知道什么是CORS去搜了一下才明白原来是浏览器的同源策略在作怪。因为前端页面是在8081端口后端接口是在8080端口端口不一样所以浏览器认为是不同的源阻止了请求。解决思路后端配置跨域。写一个CorsConfig配置类实现WebMvcConfigurer接口重写addCorsMappings方法配置允许的来源、方法、头信息这些。配置完之后前端就能正常调接口了。权限控制怎么做系统有好几种角色不同角色的权限不一样比如只有管理员才能增删改物资普通学生只能看。这个权限控制怎么实现一开始我也挺纠结的。想过用拦截器或者过滤器统一做又觉得有点复杂实训项目可能用不上。而且当时时间也比较紧怕搞复杂了反而做不完。解决思路简化处理用请求头传角色信息。前端登录后把用户角色存在请求头里后端每个需要权限控制的接口先从请求头里拿到角色判断一下有没有权限有权限才继续执行没有就返回无权限的提示。虽然这种方式不是很安全也有点重复代码但对于实训项目来说够用了实现起来也简单。日期格式化问题返回给前端的日期格式不对有时候是时间戳有时候是乱七八糟的格式前端显示起来很丑。我记得当时前端同学说你返回的日期怎么是一串数字啊我这边不好显示。我去看了一下确实createTime字段返回的是一个长整型的时间戳不是我们想要的yyyy-MM-dd HH:mm:ss格式。一开始我想在前端转后来觉得还是后端统一处理比较好这样前端不用每个地方都转。解决思路在application.yml里配置jackson的日期格式和时区这样返回给前端的日期就是统一的格式了。或者在实体类的日期字段上加JsonFormat注解也能达到同样的效果。统一返回结果的设计一开始每个接口返回的格式都不一样前端处理起来很麻烦。后来才想到要封装一个统一的返回结果类。最开始写接口的时候我都是想到什么返回什么比如查询成功就直接返回对象失败就返回一个字符串但是比较乱。后来我去查了一下发现大家都会封装一个统一的返回结果类包含状态码、提示信息、返回数据这些字段。我照着写了一个Result类又加了success和error两个静态方法用起来还挺方便的。解决思路封装一个Result类包含状态码、提示信息、返回数据三个字段再提供success和error两个静态方法。所有接口都返回Result对象前端处理起来就统一了不用每个接口都写不同的解析逻辑。3.4 团队协作类难点前后端联调问题前后端是分开开发的到联调的时候才发现各种问题比如参数名对不上、返回格式不一样、接口路径写错了之类的。我记得第一次联调的时候前端调登录接口一直说参数传不过去。我们查了半天才发现前端是用JSON格式传的而后端接口用的是RequestParam接收当然接收不到了。后来改成RequestBody接收就好了。还有一次前端说返回的数据格式不对我一看原来是我字段名写错了和前端约定的不一样。解决思路开发前先把接口定好写一份接口文档把每个接口的请求方式、路径、参数、返回值都写清楚前后端照着文档来开发。这样联调的时候就会顺利很多不会出现大的偏差。还有就是联调的时候要及时沟通遇到问题一起看一起合作才行。代码合并冲突几个人一起开发提交代码的时候经常会有冲突特别是改同一个文件的时候。我们一开始经常出现冲突每次冲突都要折腾半天。有一次两个人同时改了Controller层的代码合并的时候冲突了一大片弄了好久才解决。解决思路尽量分工明确每个人负责不同的模块减少改同一个文件的概率。提交代码前先拉取最新的代码有冲突就及时解决不要攒到一起。四、个人学习收获这次实训虽然时间不长但我感觉学到的东西比上课一学期都多毕竟是真刀真枪做项目。4.1 技术上的收获对Spring Boot项目的开发流程更熟悉了。以前上课都是学零散的知识点这次是从头到尾完整做了一个项目从环境搭建到数据库设计再到接口开发、联调测试整个流程都走了一遍。现在再让我做一个类似的项目我肯定能做得更快更好。以前我对Spring Boot的理解就是不用写配置但具体怎么用项目结构是什么样的各层之间怎么调用其实都不太清楚。这次自己动手做了一遍才真正理解了Spring Boot项目的开发模式。数据库设计能力提升了。以前总觉得建表很简单不就是几个字段嘛。真正做项目才发现表结构设计得好不好对后面的开发影响太大了。设计得好写代码的时候顺风顺水设计得不好后面改来改去麻烦得很。现在我设计表的时候会先想清楚需求考虑得更全面了。而且我也学会了怎么画ER图怎么分析实体之间的关系。以前看ER图都觉得晕现在自己能画出来了感觉还是挺有成就感的。解决问题的能力提高了。做项目的过程中遇到了各种各样的bug有些是见过的有些是从来没遇到过的。从一开始遇到bug就慌到现在能冷静地看错误信息、定位问题、找解决方案这个进步还是挺明显的。我现在遇到问题的一般思路是先看错误信息大概判断是哪一层的问题然后去网上搜看看有没有人遇到过类似的问题找到解决方案后先理解为什么会出现这个问题再动手改。这样不仅解决了问题还学到了新知识。学会了怎么查资料。遇到问题不要急着问别人先自己想想然后去网上搜大部分问题都能找到答案。而且要会看官方文档官方文档是最权威的。以前我遇到问题就喜欢问同学现在发现其实很多问题自己搜一下就能解决。而且自己找答案的过程也是一个学习的过程印象会更深刻。4.2 团队协作上的收获明白了沟通的重要性。做项目不是一个人的事是整个团队的事。有想法要及时说有问题要及时问不要憋着。很多问题其实就是沟通不到位造成的说开了就没事了。学会了怎么和别人配合。每个人的想法不一样做事方式也不一样要学会尊重别人的意见互相体谅。遇到意见不一致的时候好好商量找一个大家都能接受的方案不要钻牛角尖。体会到了团队的力量。一个人做项目遇到难点可能会卡很久但有团队就不一样了大家一起想办法问题很快就能解决。而且分工合作效率也高很多。比如这次项目如果让我一个人做可能一个月都做不完。但五个人一起两周就做完了。每个人做自己擅长的部分合起来就是一个完整的项目。4.3 其他方面的收获做事情要有规划。项目一开始就要想好要做什么、怎么做、分几步做不能上来就写代码。有规划的话进度可控也不容易漏东西。我们一开始就是先做需求分析然后设计数据库再搭框架最后写业务代码一步一步来虽然中间也有调整但整体节奏还是比较稳的。文档很重要。不管是数据库设计文档还是接口文档都很重要。不要觉得写文档浪费时间后面会省很多事。比如接口文档写好了前后端联调就很顺利不用来回问。要多总结。遇到的问题、学到的东西都要及时总结。不然过段时间就忘了下次遇到同样的问题还要再踩一次坑。写博客也是一种总结的方式逼着自己把思路理清楚。这次写这三篇博客对我来说也是一个复盘的过程。写的时候会回忆当时遇到的问题、是怎么解决的相当于又重新学了一遍。五、不足与改进方向虽然项目做完了但还是有很多不足的地方。技术上很多地方做得比较简单比如权限控制用请求头传角色肯定是不安全的正式项目肯定不能这么做。还有密码都是明文存的也没有加密这些都是安全隐患。还有就是没有做分页数据多了的话一次查所有肯定不行得加上分页查询。异常处理也比较简单都是直接返回错误信息没有统一的异常处理机制。流程上一开始需求分析做得不够细做到中间才发现有些地方没想清楚又回去改浪费了一些时间。以后做项目需求分析阶段一定要做足把问题都想清楚了再动手。测试也做得比较少基本就是自己测一下功能能不能跑没有做全面的测试。比如边界值、异常情况这些都没怎么测。以后可以学学单元测试提高代码的质量。六、总结总的来说这次实训还是很有意义的。把课堂上学的理论知识用到了实际项目中也发现了自己的很多不足。技术这条路还很长要学的东西还有很多继续加油吧。这个系列的三篇博文到这里就结束了从环境搭建到功能实现再到总结算是把整个实训过程都记录下来了。希望能对正在做类似项目的同学有一点帮助。回想起这两周的实训有熬夜改bug的痛苦也有功能跑通后的喜悦有和队友讨论问题的热烈也有答辩前的紧张。这些经历都会成为我学习路上的宝贵财富。最后感谢我们小组的所有成员大家一起努力才能在这么短的时间里完成这个项目。也感谢老师的指导在我们遇到困难的时候给我们指点方向。如果觉得文章对你有帮助欢迎点赞、收藏、关注有问题也可以在评论区交流~
校园物资报修管理系统——实训总结与个人收获
发布时间：2026/6/26 21:27:42
【实训项目】校园物资报修管理系统——实训总结与个人收获一、前言这是这个系列的第三篇博文也是最后一篇。前两篇分别介绍了项目的环境搭建和后端核心功能实现这篇来做个整体总结聊聊整个实训过程中遇到的难点、解决思路还有我的个人收获。作为小组的数据库/后端工程师我主要负责数据库设计与ER图、接口需求梳理、后端公共模块开发、演示流程梳理这些工作。整个实训做下来虽然时间不长但收获还是挺多的。其实一开始听说要做实训项目的时候我心里还是挺没底的。因为之前上课都是学零散的知识点每个知识点都是单独学的从来没有把它们串起来做一个完整的项目。而且还是小组合作我也担心自己拖后腿。但真正做下来发现虽然遇到了很多问题但一步一步解决的过程中自己也在慢慢成长。从最开始连Spring Boot项目怎么创建都要搜半天到最后能独立完成一个模块的开发这个进步还是挺明显的。写这篇总结也是想把这段时间的经历记录下来既是对自己的一个复盘也希望能给正在做类似项目的同学一点参考。如果你也在做课程设计或者实训项目遇到了类似的问题希望这篇文章能帮到你。二、实训整体总结2.1 项目完成情况我们小组这次做的是校园物资报修管理系统从需求分析到最终完成大概用了两周左右的时间。系统主要包含四大模块用户管理、物资管理、报修工单、物资申请支持管理员、学生、维修人员、老师四种角色。为什么选这个题目呢其实也是因为我们平时在学校里经常遇到物资坏了报修麻烦的情况。比如教室里的投影仪坏了要找老师、找后勤来回折腾好几天才能修好这样不仅效率低下还引起很多麻烦。如果有一个线上的报修系统学生直接在网上提交申请维修人员就能看到效率肯定会高很多。技术栈方面后端用的是Spring Boot MyBatis-Plus MySQL前端用的是HTMLCSSJavaScript前后端分离开发。整体来说核心功能都实现了基本满足了实训的要求。当然作为一个学生实训项目肯定还有很多不完善的地方。比如界面比较简单功能也比较基础和真正的商用系统比起来还差得远。但对我们来说能把学到的知识用起来做出一个能跑通的完整项目就已经很有意义了。2.2 我的工作内容作为数据库/后端工程师我主要做了这些工作第一数据库设计。这是我最开始做的工作也是整个项目的基础。我先梳理了系统的实体和关系画了ER图然后设计了四张核心表用户表、物资表、报修工单表、物资申请表。表结构设计的时候考虑了字段类型、索引、约束这些尽量做到合理规范。说起来简单做起来其实花了不少时间。一开始我设计的表特别简单用户表就只有id、用户名、密码三个字段。后来和前端同学沟通发现页面上要展示真实姓名、角色、手机号、状态这些信息又回去加字段。来来回回改了三四版才最终定下来。现在回头看数据库设计真的是项目的地基。地基打牢了后面盖房子就快地基没打好后面盖着盖着就会出问题。第二接口需求梳理。数据库设计完之后我和前端同学一起梳理了需要哪些接口每个接口的请求方式、参数、返回值是什么。整理了一份接口文档前后端照着这个来开发联调的时候就顺利多了。这部分工作虽然不是写代码但我觉得挺重要的。以前总觉得写代码才是正事文档什么的都是浪费时间。这次才发现接口文档写清楚了前后端各干各的最后合到一起的时候基本没什么大问题反而节省了时间。第三后端公共模块开发。比如统一返回结果封装、跨域配置这些都是项目一开始就要搭好的基础。这些东西虽然不是业务功能但对后面的开发影响很大搭好了后面写业务代码就很顺畅。我记得当时搭统一返回结果的时候一开始是每个接口自己返回不同的东西有的直接返回对象有的返回字符串乱得很。后来觉得太乱了我就去查了查怎么封装统一返回结果写了个Result类。改完之后所有接口都返回Result前端处理起来也方便多了。第四后端业务功能开发。主要是用户管理、物资管理、工单管理这些模块的后端接口包括增删改查和一些业务逻辑。写业务代码的过程中我对三层架构的理解也更深了。以前只是知道Controller、Service、Mapper这三层但为什么要这么分每层具体干什么其实不太清楚。这次自己写了一遍才明白分层的好处职责清晰出了问题知道去哪一层找以后要改也方便。第五演示流程梳理。项目做完之后我还梳理了演示的流程从登录开始到各个功能的演示顺序确保演示的时候能把系统的核心功能都展示出来。2.3 小组成员配合我们小组一共五个人分工还是比较明确的。大家配合得还不错有问题一起讨论遇到bug一起排查。虽然中间也有过意见不一致的时候但最后都能商量出解决方案。团队合作就是这样每个人都有自己的想法有分歧很正常。关键是要好好沟通站在对方的角度想一想找到一个大家都能接受的方案。还有就是代码合并的时候一开始我们都是互相发文件你拷给我我拷给你特别麻烦还经常覆盖别人的代码。但后来我们改正了比如每个人负责不同的模块尽量不要改同一个文件提交代码前先拉取最新的有冲突及时解决。总的来说我们小组的氛围还是很好的大家都很认真也很愿意帮忙。谁遇到问题了喊一声其他人都会过来一起看。能和这样的队友一起做项目我觉得挺幸运的。三、项目难点与解决思路整个实训过程中遇到了不少问题有些是环境搭建的坑有些是开发中的技术难点。这里挑几个印象深的说说前两篇博文里提到的也一起总结一下。3.1 环境搭建类难点MySQL 8.0的各种坑这是最开始就遇到的问题也是踩坑最多的地方。第一个是驱动类名MySQL 8.0的驱动类名和5.7的不一样一开始照搬5.7的配置启动一直报错。我记得当时启动项目控制台报了一大片红看得我头都大了。仔细看错误信息说是无法加载驱动类。我反复检查了pom.xml里的依赖版本是对的啊怎么会找不到呢后来去网上搜才知道MySQL 8.0的驱动类名变了不是以前的了。就这一个MySQL的问题折腾了我快一个下午。现在想想其实都是很基础的问题但因为不熟悉就卡了很久。所以说环境搭建虽然不是什么高深的技术但也很重要环境搭不好后面根本没法开发。解决思路遇到报错先看错误信息然后去网上搜基本上这些常见问题都有解决方案。后来我专门把MySQL 8.0和5.7的区别记了一下避免以后再踩同样的坑。Maven依赖下载慢这个也是很多人都会遇到的问题默认的Maven中央仓库在国内访问很慢经常下载超时。我记得第一次创建Spring Boot项目的时候Maven下载依赖下载了快半个小时还经常失败重试了好几次才成功。当时我就想这也太慢了每次创建新项目都要等这么久吗后来也是讨论了一下然后搜索可以配置阿里云镜像下载速度会快很多。在settings.xml里加上了阿里云的mirror配置再下载的时候速度真的快了好多基本上几秒钟就下完了。解决思路配置阿里云镜像。在settings.xml里加上阿里云的mirror配置下载速度直接快好几倍。这个虽然不是技术难点但很影响效率早配置早省心。端口号被占用启动报错Web server failed to start. Port 8080 was already in use启动的时候报错看到8080我就感觉到肯定是端口号出现问题了本来想抱着试试的心态改一下端口号发现可以正常启动了。**解决思路**要么关掉占用的程序要么改配置换个端口。我个人认为换个端口号更加方便也不用考虑其他。3.2 数据库设计类难点表结构设计的合理性这是我遇到的第一个真正意义上的难点。以前上课都是照着题目写SQL真正自己设计表的时候才发现没那么简单。比如用户表到底要哪些字段字段类型选什么要不要加索引外键要不要加这些都要考虑。一开始我设计的表很简单用户表就id、用户名、密码三个字段工单表也就id、标题、内容几个字段。后来做着做着发现缺字段比如用户需要真实姓名、角色、手机号工单需要报修人、维修人员、状态、创建时间又回去加来来回回改了好几次。还有外键的问题一开始我给所有关联的表都加了物理外键结果删数据的时候特别麻烦经常因为外键约束删不掉。后来才知道很多项目里都不用物理外键而是用逻辑外键也就是只在代码层面维护关联关系数据库层面不加外键约束。这样删数据方便性能也更好。解决思路先把需求理清楚把所有实体和属性都列出来然后再设计表。设计完之后和小组同学一起讨论看看有没有遗漏的有没有不合理的地方。还有就是多参考一下成熟项目的表结构学习一下别人是怎么设计的。另外外键这个东西开发阶段其实可以不用物理外键用逻辑外键就行不然删数据的时候很麻烦还影响性能。这个也是我后来才知道的。实体类和数据库字段的映射问题实体类用的是驼峰命名数据库用的是下划线命名一开始查出来的数据有些字段是null找了半天才发现是映射的问题。我记得当时做用户登录功能查出来的用户对象username和password都有值但realName、createTime这些字段都是null。我反复检查SQL字段名是对的啊怎么会查不出来呢后来仔细对比了一下才发现数据库里的字段是real_name、create_time而实体类里是realName、createTime。原来是驼峰命名和下划线的映射问题。我以为MyBatis-Plus会自动处理这个后来才知道虽然MyBatis-Plus默认开启了驼峰命名自动映射但如果是自己写XML的话有时候会不生效。后来我在application.yml里显式配置了一下就正常了。解决思路MyBatis-Plus默认是开启驼峰命名自动映射的但如果是自己写XML的话要注意配置一下或者用resultMap手动映射。后来我在application.yml里配置了一下就正常了。3.3 后端开发类难点跨域问题前后端分离开发前端和后端端口不一样浏览器的同源策略会阻止请求也就是跨域问题。一开始前端调接口一直报错还以为是接口写错了后来才知道是跨域的问题。我记得当时前端同学说接口调不通我还说不可能啊我用Postman测都是好的。然后我们一起看浏览器的控制台发现报了一个CORS的错误。我当时还不知道什么是CORS去搜了一下才明白原来是浏览器的同源策略在作怪。因为前端页面是在8081端口后端接口是在8080端口端口不一样所以浏览器认为是不同的源阻止了请求。解决思路后端配置跨域。写一个CorsConfig配置类实现WebMvcConfigurer接口重写addCorsMappings方法配置允许的来源、方法、头信息这些。配置完之后前端就能正常调接口了。权限控制怎么做系统有好几种角色不同角色的权限不一样比如只有管理员才能增删改物资普通学生只能看。这个权限控制怎么实现一开始我也挺纠结的。想过用拦截器或者过滤器统一做又觉得有点复杂实训项目可能用不上。而且当时时间也比较紧怕搞复杂了反而做不完。解决思路简化处理用请求头传角色信息。前端登录后把用户角色存在请求头里后端每个需要权限控制的接口先从请求头里拿到角色判断一下有没有权限有权限才继续执行没有就返回无权限的提示。虽然这种方式不是很安全也有点重复代码但对于实训项目来说够用了实现起来也简单。日期格式化问题返回给前端的日期格式不对有时候是时间戳有时候是乱七八糟的格式前端显示起来很丑。我记得当时前端同学说你返回的日期怎么是一串数字啊我这边不好显示。我去看了一下确实createTime字段返回的是一个长整型的时间戳不是我们想要的yyyy-MM-dd HH:mm:ss格式。一开始我想在前端转后来觉得还是后端统一处理比较好这样前端不用每个地方都转。解决思路在application.yml里配置jackson的日期格式和时区这样返回给前端的日期就是统一的格式了。或者在实体类的日期字段上加JsonFormat注解也能达到同样的效果。统一返回结果的设计一开始每个接口返回的格式都不一样前端处理起来很麻烦。后来才想到要封装一个统一的返回结果类。最开始写接口的时候我都是想到什么返回什么比如查询成功就直接返回对象失败就返回一个字符串但是比较乱。后来我去查了一下发现大家都会封装一个统一的返回结果类包含状态码、提示信息、返回数据这些字段。我照着写了一个Result类又加了success和error两个静态方法用起来还挺方便的。解决思路封装一个Result类包含状态码、提示信息、返回数据三个字段再提供success和error两个静态方法。所有接口都返回Result对象前端处理起来就统一了不用每个接口都写不同的解析逻辑。3.4 团队协作类难点前后端联调问题前后端是分开开发的到联调的时候才发现各种问题比如参数名对不上、返回格式不一样、接口路径写错了之类的。我记得第一次联调的时候前端调登录接口一直说参数传不过去。我们查了半天才发现前端是用JSON格式传的而后端接口用的是RequestParam接收当然接收不到了。后来改成RequestBody接收就好了。还有一次前端说返回的数据格式不对我一看原来是我字段名写错了和前端约定的不一样。解决思路开发前先把接口定好写一份接口文档把每个接口的请求方式、路径、参数、返回值都写清楚前后端照着文档来开发。这样联调的时候就会顺利很多不会出现大的偏差。还有就是联调的时候要及时沟通遇到问题一起看一起合作才行。代码合并冲突几个人一起开发提交代码的时候经常会有冲突特别是改同一个文件的时候。我们一开始经常出现冲突每次冲突都要折腾半天。有一次两个人同时改了Controller层的代码合并的时候冲突了一大片弄了好久才解决。解决思路尽量分工明确每个人负责不同的模块减少改同一个文件的概率。提交代码前先拉取最新的代码有冲突就及时解决不要攒到一起。四、个人学习收获这次实训虽然时间不长但我感觉学到的东西比上课一学期都多毕竟是真刀真枪做项目。4.1 技术上的收获对Spring Boot项目的开发流程更熟悉了。以前上课都是学零散的知识点这次是从头到尾完整做了一个项目从环境搭建到数据库设计再到接口开发、联调测试整个流程都走了一遍。现在再让我做一个类似的项目我肯定能做得更快更好。以前我对Spring Boot的理解就是不用写配置但具体怎么用项目结构是什么样的各层之间怎么调用其实都不太清楚。这次自己动手做了一遍才真正理解了Spring Boot项目的开发模式。数据库设计能力提升了。以前总觉得建表很简单不就是几个字段嘛。真正做项目才发现表结构设计得好不好对后面的开发影响太大了。设计得好写代码的时候顺风顺水设计得不好后面改来改去麻烦得很。现在我设计表的时候会先想清楚需求考虑得更全面了。而且我也学会了怎么画ER图怎么分析实体之间的关系。以前看ER图都觉得晕现在自己能画出来了感觉还是挺有成就感的。解决问题的能力提高了。做项目的过程中遇到了各种各样的bug有些是见过的有些是从来没遇到过的。从一开始遇到bug就慌到现在能冷静地看错误信息、定位问题、找解决方案这个进步还是挺明显的。我现在遇到问题的一般思路是先看错误信息大概判断是哪一层的问题然后去网上搜看看有没有人遇到过类似的问题找到解决方案后先理解为什么会出现这个问题再动手改。这样不仅解决了问题还学到了新知识。学会了怎么查资料。遇到问题不要急着问别人先自己想想然后去网上搜大部分问题都能找到答案。而且要会看官方文档官方文档是最权威的。以前我遇到问题就喜欢问同学现在发现其实很多问题自己搜一下就能解决。而且自己找答案的过程也是一个学习的过程印象会更深刻。4.2 团队协作上的收获明白了沟通的重要性。做项目不是一个人的事是整个团队的事。有想法要及时说有问题要及时问不要憋着。很多问题其实就是沟通不到位造成的说开了就没事了。学会了怎么和别人配合。每个人的想法不一样做事方式也不一样要学会尊重别人的意见互相体谅。遇到意见不一致的时候好好商量找一个大家都能接受的方案不要钻牛角尖。体会到了团队的力量。一个人做项目遇到难点可能会卡很久但有团队就不一样了大家一起想办法问题很快就能解决。而且分工合作效率也高很多。比如这次项目如果让我一个人做可能一个月都做不完。但五个人一起两周就做完了。每个人做自己擅长的部分合起来就是一个完整的项目。4.3 其他方面的收获做事情要有规划。项目一开始就要想好要做什么、怎么做、分几步做不能上来就写代码。有规划的话进度可控也不容易漏东西。我们一开始就是先做需求分析然后设计数据库再搭框架最后写业务代码一步一步来虽然中间也有调整但整体节奏还是比较稳的。文档很重要。不管是数据库设计文档还是接口文档都很重要。不要觉得写文档浪费时间后面会省很多事。比如接口文档写好了前后端联调就很顺利不用来回问。要多总结。遇到的问题、学到的东西都要及时总结。不然过段时间就忘了下次遇到同样的问题还要再踩一次坑。写博客也是一种总结的方式逼着自己把思路理清楚。这次写这三篇博客对我来说也是一个复盘的过程。写的时候会回忆当时遇到的问题、是怎么解决的相当于又重新学了一遍。五、不足与改进方向虽然项目做完了但还是有很多不足的地方。技术上很多地方做得比较简单比如权限控制用请求头传角色肯定是不安全的正式项目肯定不能这么做。还有密码都是明文存的也没有加密这些都是安全隐患。还有就是没有做分页数据多了的话一次查所有肯定不行得加上分页查询。异常处理也比较简单都是直接返回错误信息没有统一的异常处理机制。流程上一开始需求分析做得不够细做到中间才发现有些地方没想清楚又回去改浪费了一些时间。以后做项目需求分析阶段一定要做足把问题都想清楚了再动手。测试也做得比较少基本就是自己测一下功能能不能跑没有做全面的测试。比如边界值、异常情况这些都没怎么测。以后可以学学单元测试提高代码的质量。六、总结总的来说这次实训还是很有意义的。把课堂上学的理论知识用到了实际项目中也发现了自己的很多不足。技术这条路还很长要学的东西还有很多继续加油吧。这个系列的三篇博文到这里就结束了从环境搭建到功能实现再到总结算是把整个实训过程都记录下来了。希望能对正在做类似项目的同学有一点帮助。回想起这两周的实训有熬夜改bug的痛苦也有功能跑通后的喜悦有和队友讨论问题的热烈也有答辩前的紧张。这些经历都会成为我学习路上的宝贵财富。最后感谢我们小组的所有成员大家一起努力才能在这么短的时间里完成这个项目。也感谢老师的指导在我们遇到困难的时候给我们指点方向。如果觉得文章对你有帮助欢迎点赞、收藏、关注有问题也可以在评论区交流~
