Project Name: Health Code Management System
Group size: 6 people
I am responsible for: web backend development
Project achievements: small program client, web management client, project documents (project prospect and scope documents, prototype interface, use case documents, requirement function specifications, database design documents, uml design documents, test reports, user manuals)
Next, follow the chronological order of the project process to review~
Prototype interface development
The beginning of the prototype interface is an important way to help us confirm the requirements and improve the usability of the project. In the process of designing the prototype interface, we used the "Ink Knife" web version, selected a prototype in the material library with a style similar to ours as the basis, and modified it on it (in the end we did implement it according to the prototype ). During the acceptance process, I noticed that many groups did not design prototypes (referring to generating front-end pictures), but directly used front-end templates, directly changed the front-end code and took screenshots as prototype interfaces. The method of directly using the front-end template saves a lot of coding process from 0 to 1 in the follow-up work. During the implementation process, I noticed that the construction period of the front-end of other groups is obviously much shorter than ours, and the interface is relatively more beautiful. It can be said that it is impossible for us to implement the front end from 0 to 1 next time ~
During the acceptance process, the teacher not only paid attention to the completeness and reasonableness of the functions, but also focused on the details, such as: the confirmation button should be on the far right of the interface. We haven’t studied design before. At that time, I felt that the teacher was looking for faults (bushi). Now, looking back, it does make sense. In real life, similar buttons on websites are generally on the right (seemingly).
Example web backend prototype diagram
Small program terminal example
use case document
Since our project has a larger workload than the average project, there are many more use cases (about 60+) than the average group. The use case document feels like the function we expect the system to eventually have, requiring complete functions and clear logic.
Here I have to criticize myself. Due to the subsequent changes, the functions contained in the final project and the use case document are not completely consistent. Many times it becomes what to think of (the front end asks the back end to provide the interface), resulting in the final function It is not completely complete, and due to the difference between the actual function and the use case document, a version of the use case document was revised according to the finished product before submission...
Database Design
数据库设计使用了power designer来生成ER图，并转化为SQL语句。设计过程中我们展开了激烈的讨论，解决了一些问题，但也有一些没考虑到或者没有好办法的问题被迫保留。
解决了
两表的主键互为外键：
在设计时，为了体现两表之间的关联性和可维护性，我们设计了一些外键。但是在实际使用中就遇到了两表互为外键，例如区县防疫办的id作为超级管理者的外键，而超级管理者的id也作为区县防疫办的外键。这就导致了在第一次新增数据时，由于两表都为空，无法使用外键，从而都无法顺利的插入数据。发现这个问题后我们又重新检查了设计好的数据库，最终觉得按照管理关系，去掉区县防疫办中关于超级管理者的外键，从而顺利的插入数据。
据分析，两表主键互为外键应该是一个设计问题，类似与死锁，并不合理，在首次插入时会造成极大问题。如果两表主键必须互为外键，可以在按照以上方法插入数据后，再重新设置外键；如果两表中已经存在其他数据对象，先插入的对象还可以先引用表的其他对象作为外键，待二者都完成插入，再修改外键。
物理删除和逻辑删除：
由于一些外键的存在，我们在某些情况下不方便将数据对象直接从表中物理删除，这是就需要在表中添加新字段deleted来标识这个对象是否被删除，其中0表示未删除，1表示删除。当我们使用mybatis-plus框架时，对数据执行删除操作，就会自动将deleted字段赋为1，并无法查询。如果使用自己设置的查询语句，则应注意在需要时手动添加判断deleted是否为1的条件。
乐观锁的应用：
为在保证数据库读写效率的同时，防止在并发操作时出现线程安全问题，我们在数据库中添加了version字段。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。需要注意的是，我们需要添加项目的配置文件来启动乐观锁机制。
未解决
固定核酸检测点的时间问题
由于固定监测点的时间，所有需要按照星期来进行设置。但是一星期中每天的具体时间又不同，最终只好采取了星期几+上下文的方式来存时间（7*2列）。导致无论是在使用过程中还是在编码过程中都非常的麻烦，可用性不高，但又想不到什么好的解决办法...
未发现
很多表和字段并未使用或未设计
在设计时，我们根据需求和自己的判断完成了一个数据库，但是在编码时还是常常遇到问题，归其根本还是设计数据库时考虑不周。这或许就需要我们在一个个项目中慢慢的积累经验，了解数据库设计的原则和可用性，提高自己的设计水平。
α版本开发
从这里才开始算是正式写代码~
致谢：感谢黑马讲了代码生成器，要不创建项目不知道要花多久呢
除去第一天晚上熟悉框架和mybatis-plus的时间，大概三天左右就把α版本的后端接口基本完成了。当然只是我以为的完成...由于没有注意到代码质量和异常处理等问题，最后在验收前可没少填坑...由于忽视了很多需要在后端完成的异常处理，导致在项目测试时经常出现卡死或无反应等情况，麻烦前端的同学一点一点加js了...
项目搭建后我们还导入或编写了一些工具类，比如Result返回类型、JsonUtils工具类、Authentication身份信息验证类、JacksonObjectMapper对象映射器等等，在后续的开发中这些类多多少少发挥着作用。
后端测试使用了Apifox，一开始我们都以为接口通过了前后端交互就没啥问题，但是在开始阶段还遇到了一些配置问题，最经典的就是Vue的跨域问题了，虽然解决后认识到是一个比较固定的配置问题，但是在开发过程中还是为了前后端交互发了不少愁...
β版本开发
首先根据α版本的开发情况，对用例文档进行修改，明确接下来的开发方向。我们除了删去了一些和项目关系不太大的版块，还根据实际的上线情况和资源情况进行了调整（比如由于健康码的特殊性，没有办法上线小程序...只能说这项目太特殊了）
后端的代码开发和前面也有一些改变：
由于联合查询的出现，新建和使用DTO类
根据数据库范式的相关知识，我们不能直接把要用到所有信息存到一张表里，常用联合查询的情况，这时候就需要我们新建DTO类来继承初始类，并添加新的信息以供使用。
redis的使用
随着测试的数据量不断加大，一些查询甚至是需要5s左右才能返回结果，体验非常不好，所有引入了redis作为缓存来提高查询效率。同时在redis也用到了验证码部分，根据redis缓存时间的特性，来实现了固定时间内的短信验证码验证功能。
测试
在此之前我们也没有接触过测试的相关培训和知识，也不会使用自动化的测试工具，就凭借自己的感觉来测试功能（例如 随便乱输）。你别说，你还真别说，还真遇到了大问题...由于没有进行前端没有考虑js校验，后端也没用进行异常处理，这下随便输什么信息都能存到数据库或者报异常...现在想起来真是追悔莫及...最后项目也是在这个问题上扣了不少分（按bug个数扣分，我们的功能又多，重复扣了好多次...感谢xxr老师）。还有一些由于外键连接导致的删除数据后查询异常的问题（就该把他整成禁止删除的），反正搞得乱糟糟的，肯定要重新构思实现了...
整个项目到这里基本上就结束了，最后应该还被老师拿去放到新书里当案例了，课程评优三等奖，但是回过头来看项目还有很多可以调优和改进的地方（安全性、响应速度、用户体验等），暂时就给后续的项目当个反面典型得了
整个合作过程还算是比较轻松愉快的，当时分组就挑选了平时一起学习的伙伴，大家的水平和技术栈也相对来说比较相似，大多也肯干能干（就是对自己很自信才选了个大项目，但是这评分机制我是真的无力吐槽了...），在某部分比较忙的时候也少不了大家互相客串一下来完成任务（被迫全栈），如果有机会再一起写项目的话（那肯定有），希望我们能做出真正符合使用需求的优秀项目！