122
社区成员
发帖
与我相关
我的任务
分享护林员——GitCode团队实战总结
| 这个作业属于哪个课程 | 福州大学-202302软件工程实践 |
|---|---|
| 这个作业要求在哪里 | 软工实践——GitCode团队实战总结 |
| 这个作业的目标 | 多人协同工作、事先设计好模块分工、团队博客发表一篇博客 |
| 团队名称 | 护林员 |
目录
- 一、项目地址
- 二、GitCode 的提交日志截图
- 三、程序运行环境
- 四、功能实现思路描述
- 1. 功能模块分析
- 2. 具体实现思路
- 3. 问题思考
- 五、程序截图说明
- 1. 后端代码
- 1.1 数据填充
- 1.2 用户注册
- 1.3 获取用户信息
- 2. 前端页面
- 2.1 注册页面
- 2.2. 登录页面
- 2.3. 投票页面
- 2.4. 投票排名页面
- 2.5. 数据安全
- 2.6. 后台登录页面
- 2.7. 用户管理页面
- 2.8. 投票信息管理页面
- 六、组员职责分工
- 七、组员贡献度比例
- 八、合作中遇到的困难及解决方法
- 九、PSP表格
- 十、压力测试
- 1. 工具选择
- 2. 步骤
- 3. 测试结果
- 3.1 登录接口同时进行1000请求
- 3.2 登录接口请求量达到8000
- 3.3运动员排名接口请求量为2000
- 4. 改进思路
- 5. 百万级压力测试
一、项目地址
二、GitCode 的提交日志截图
- 222100434黄楠
- 222100129梅明胜
- 222100101卢雨纯
- 222100128黄煦陶
- 222100221林炳昌
- 222100304林雅婷
- 222100404余诗怡
- 222100411刘畅
成员 commit次数 222100434黄楠 16 222100129梅明胜 28 222100101卢雨纯 3 222100128黄煦陶 8 222100221林炳昌 8 222100304林雅婷 7 222100404余诗怡 12 222100411刘畅 6
三、程序运行环境
- 平台：阿里云
- 操作系统：CentOS 7
- 数据库：MySQL 8.0
- Redis：Redis 6.2
- 应用容器引擎：Docker
四、功能实现思路描述
1. 功能模块分析
2. 具体实现思路
- 登录模块
- 用户注册时会送5张票
- 用户基本信息使用数据库存储，用户IP信息使用Redis存储
- 使用手机号和验证码验证
- 投票模块
- 按照比赛可以筛选显示的运动员
- 运动员右侧有投票按钮
- 排名模块
- 按照票数进行排名
- 为了通知投票结果，会高亮已投运动员
- 管理员模块（该附加功能延时完成）
- 登录部分复用用户登录
- 投票信息查询数据库
- 用户信息查询数据库和Redis
3. 问题思考
- 用户如何快速知道有投票功能并参与投票？
页面最上方就是投票和排名，简洁明了，没有过多的花里胡哨的广告等，加快访问速度并减小上手难度，体现了我们产品对用户体验，操作方便性、快捷性的目标和追求
- 投票结果如何告知用户？
在排名页面高亮用户投过的运动员，使用户一眼就可以看到自己喜爱的运动员排名，如果排名靠前，用户会欣喜若狂，分享排名结果，吸引更多用户；如果排名靠后，高亮会让用户召集其他粉丝，为该运动员加油助威，吸引更多用户。
- 如何保证一人一号？防止用户多次注册账号参与投票？
注册账号时，会判断该手机号是否已经注册，以此来增加一人一号的可能性。同时管理员也可以在后台查看IP对应的账号数，如果某一IP账号过多，则极有可能是一人多号，应考虑封禁该IP所有账号
五、程序截图说明
1. 后端代码
1.1 数据填充
- 虽然有数据，但数据都是以JSON文件存储，为了方便后期查表等操作，故将JSON文件读入数据库中
1.2 用户注册
- 使用RegisterDTO来接收前端传来的参数，验证该手机号是否已注册后进行数据库插入，接着返回信息给前端，并在最后使用Redis记录IP地址，以及IP地址的账号数
1.3 获取用户信息
- 通过Mapper找到所有用户信息，除获取基本信息外，主要还将后端的状态变量从整型变为字符串，计算已投票数，通过Redis找到IP对应的账号数量
2. 前端页面
2.1 注册页面
- 用户输入用户名、手机号和地址后，前台验证数据是否为空，以及电话号码格式是否正确，全部合规才发送验证码，用户填入验证码后即注册
2.2. 登录页面
- 用户输入的手机号如果不正确，将会有所提示
2.3. 投票页面
- 上方一个下拉框选择赛事，默认是所有比赛，即可显示所有运动员。
如果选择其中一个比赛，则只显示部分运动员：
下拉框下面显示改用户剩余的投票数，用户对运动员的投票不能超过该值。用户通过按钮选择投票数后，点击确定按钮即可投票，用户的剩余投票数自动减少，并且该运动员的投票数自动清零，不允许用户对投票更改：
2.4. 投票排名页面
- 根据运动员投票数量，从高到低排序，如果自己对某个运动员投过票，则高亮显示：
2.5. 数据安全
- 未登录或者注册的用户不允许投票和查看排名
2.6. 后台登录页面
- 管理员输入手机号和验证码进行登录
2.7. 用户管理页面
- 可以在操作下点击“启用”和“禁封”按钮对用户进行权限管理
2.8. 投票信息管理页面
- 查看所有投票纪录
六、组员职责分工
| 成员 | 任务 |
|---|---|
| 222100434黄楠 | 投票模块、投票信息获取、前后端集成测试、服务器部署、博客 |
| 222100129梅明胜 | 前端所有接口和数据处理、前后端集成测试 |
| 222100101卢雨纯 | 投票页、博客 |
| 222100128黄煦陶 | 用户登录页、用户注册页、管理员登录页 |
| 222100221林炳昌 | 登录模块、管理员登录、用户信息获取、帮助他人分析Bug |
| 222100304林雅婷 | 排名模块、修改用户状态、压力测试 |
| 222100404余诗怡 | 排名页、用户列表页 |
| 222100411刘畅 | 解决部分环境问题、博客内容收集 |
七、组员贡献度比例
| 成员 | 贡献度 |
|---|---|
| 222100434黄楠 | 19 |
| 222100129梅明胜 | 18 |
| 222100101卢雨纯 | 5 |
| 222100128黄煦陶 | 13 |
| 222100221林炳昌 | 15 |
| 222100304林雅婷 | 15 |
| 222100404余诗怡 | 14 |
| 222100411刘畅 | 1 |
八、合作中遇到的困难及解决方法
222100434黄楠
- 遇到的困难
- 对进度的把握不够精准，导致附加功能管理员页面在截止后才完成
- 接口文档多变，版本确定困难
- 测试接口困难又耗时，每次需要重新部署到服务器上
- 解决办法
- 未来需要需要掌握前端进度和任务安排，及时要求拆分工作量过大，一人无法完成的任务
- 要求前端人员给出计划表，确保未完成任务时可以及时解决，分配给他人
- 学习使用apifox，简化测试接口流程，并使得接口文档的改变可以实时同步
- 心得体会
- 软件工程真的应该像之前原型设计一样，在系统设计说明书作业中，要求使用相关工具，这样可以打破信息差，直接就能一步到位使用先进的工具
- 作为PM，不能因为不会前端就将其全部丢给前端负责人，这样既加重了前端负责人的压力，又无法让自己掌握项目整体的进度
- 如果团队内有大佬提出建议，一定要尽快思考其深意，比如apifox的使用，如果我曾经真的去了解过它，很有可能早在Alpha开始前就要求所有人去学习该工具了，而不是现在匆匆忙忙的借着Git实战作业的机会去学习
- 遇到的困难
222100129梅明胜
- 遇到的困难
- pinia状态管理中，被getter出去的变量isLogined不能被state初始化，一直显示undefined 。导致网络请求数据接不上
- 解决办法
- 不断地一层层的console.log输出信息排查
- 心得体会
- 好离谱的设定，搜也搜不到原因。折腾了我好久。
- 遇到的困难
222100101卢雨纯
- 遇到的困难：
- 新特性在不同浏览器上的渲染不一致，导致兼容性问题。
- 团队成员的代码风格和命名习惯差异较大，导致代码可读性下降。
- 解决办法：
- 入Polyfill和添加浏览器前缀来解决兼容性问题。
- 通过代码审查来统一代码风格，并通过Pull Request合并更改，减少冲突。
- 心得体会
- 在这次前端开发中，我深刻体会到了跨浏览器兼容性的重要性，以及使用工具如Polyfill来确保应用在不同环境下的一致性。团队协作中，统一的代码规范对于保持项目的健康至关重要。这次经历让我认识到了团队协作的力量，以及在开发过程中持续改进的重要性。
- 遇到的困难：
222100128黄煦陶
- 遇到的困难
- 在开发过程中，前端和后端的接口对接可能会出现不匹配的情况。
- 随着应用状态的增加，管理状态变得越来越复杂。
- 多人协作时，代码合并可能会产生冲突。
- 解决办法
- 与后端团队密切沟通：定期与后端团队开会，确保接口设计的一致性和可行性。
- 制定代码合并规则：在团队中制定明确的代码提交和合并规则，减少冲突的发生。
- 心得体会
- 这次实践使我深刻体会到在团队中保持良好沟通的必要性，遵循良好的编码规范对提高代码质量和团队协作效率十分重要，同时充分的测试是确保产品质量的关键，让我们的项目更加稳健。总的来说，这次经历不仅锻炼了我的技术能力，也提高了我的团队协作和问题解决能力。
- 遇到的困难
222100221林炳昌
- 遇到的困难
- 时间有点极限，代码编写以及商量接口都需要不少时间
- 解决办法
- 编写简洁版的接口文档，采用相对简单的技术栈
- 心得体会
- 在团队配合上还有待提升
- 遇到的困难
222100304LYT
- 遇到的困难
- 运动员排名接口返回数据包含该用户是否给运动员投票的bool值，需要进行联表查询，sql语句较为复杂
- 对压力测试一窍不通
- 解决办法
- 复习数据库相关知识、学习相关压力测试教程
- 心得体会
- 知识是会遗忘的，需要通过实践来巩固和深化。另外也需要不断更新知识和技能，以满足任务的技术需求。
- 遇到的困难
222100404余诗怡
- 遇到的困难
- 无法正常运行npm run dev指令
- 对项目接口部分编写不是很熟练，不知道怎么写
- 解决办法
- 检查发现没有在根目录运行，以及缺少一些项目依赖，运行npm i指令后成功解决
- 网上搜索相关资料学习
- 心得体会
- 在运行项目时要仔细检查环境
- 对接口的编写要多多学习。
- 遇到的困难
222100411刘畅
- 遇到的困难
- 存在较为复杂的技术以及想不出来的算法
- 解决办法
- 上b站查询相关视频，上csdn上搜寻解决方案，询问技术水平高的同学
- 心得体会
- 团队合作有助于促进技术交流和提升自身能力
- 遇到的困难
九、PSP表格
222100434黄楠
PSP Personal Software Process Stages 预计耗时（分钟） 实际耗时（分钟） Planning 计划 30 60 Estimate 估计这个任务需要多少时间 10 5 Development 开发 300 270 Analysis 需求分析 (包括学习新技术) 60 120 Coding Standard 代码规范 (为目前的开发制定合适的规范) 5 3 Coding 具体编码 300 280 Test 测试（自我测试，修改代码，提交修改） 120 260 Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 60 60 合计 885 1058 222100129梅明胜
PSP Personal Software Process Stages 预计耗时（分钟） 实际耗时（分钟） Planning 计划 10 8 Estimate 估计这个任务需要多少时间 5 5 Development 开发 1200 1800 Analysis 需求分析 (包括学习新技术) 30 15 Coding Standard 代码规范 (为目前的开发制定合适的规范) 5 5 Coding 具体编码 1000 1400 Test 测试（自我测试，修改代码，提交修改） 200 400 Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 30 30 合计 1280 1863 222100101卢雨纯
PSP Personal Software Process Stages 预计耗时（分钟） 实际耗时（分钟） Planning 计划 20 25 Estimate 估计任务所需时间 40 45 Development 开发 400 450 Analysis 需求分析（学习新技术） 50 40 Coding Standard 代码规范 15 20 Coding 具体编码 200 220 Test 测试（自我测试，修改代码，提交修改） 80 95 Postmortem & Process Improvement Plan 事后总结，提出改进计划 20 25 合计 775 880 222100128黄煦陶
PSP Personal Software Process Stages 预计耗时（分钟） 实际耗时（分钟） Planning 计划 30 35 Estimate 估计任务所需时间 60 75 Development 开发 300 350 Analysis 需求分析（学习新技术） 60 50 Coding Standard 代码规范 20 25 Coding 具体编码 150 180 Test 测试（自我测试，修改代码，提交修改） 90 100 Postmortem & Process Improvement Plan 事后总结，提出改进计划 30 40 合计 720 800 222100221林炳昌
PSP Personal Software Process Stages 预计耗时（分钟） 实际耗时（分钟） Planning 计划 30 30 Estimate 估计这个任务需要多少时间 10 5 Development 开发 180 150 Analysis 需求分析 (包括学习新技术) 20 20 Coding Standard 代码规范 (为目前的开发制定合适的规范) 10 5 Coding 具体编码 120 130 Test 测试（自我测试，修改代码，提交修改） 60 40 Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 20 20 合计 450 400 222100304LYT
PSP Personal Software Process Stages 预计耗时（分钟） 实际耗时（分钟） Planning 计划 10 15 Estimate 估计这个任务需要多少时间 15 10 Development 开发 120 160 Analysis 需求分析 (包括学习新技术) 30 20 Coding Standard 代码规范 (为目前的开发制定合适的规范) 10 10 Coding 具体编码 230 300 Test 测试（自我测试，修改代码，提交修改） 50 100 Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 40 40 合计 505 655 222100404余诗怡
PSP Personal Software Process Stages 预计耗时（分钟） 实际耗时（分钟） Planning 计划 10 8 Estimate 估计这个任务需要多少时间 10 8 Development 开发 80 550 Analysis 需求分析 (包括学习新技术) 20 30 Coding Standard 代码规范 (为目前的开发制定合适的规范) 10 15 Coding 具体编码 50 515 Test 测试（自我测试，修改代码，提交修改） 30 40 Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 10 10 合计 130 608 222100411刘畅
PSP Personal Software Process Stages 预计耗时（分钟） 实际耗时（分钟） Planning 计划 60 60 Estimate 估计这个任务需要多少时间 360 420 Development 开发 180 180 Analysis 需求分析 (包括学习新技术) 120 180 Coding Standard 代码规范 (为目前的开发制定合适的规范) 30 30 Coding 具体编码 120 150 Test 测试（自我测试，修改代码，提交修改） 60 60 Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 60 90 合计 570 690
十、压力测试
1. 工具选择
- 使用Jmeter工具进行测试
- 工具使用参考链接：使用Jmeter进行压力测试的完整步骤
2. 步骤
- 创建线程组。在 JMeter 中，线程组用于模拟一定数量的用户（以下为第一次测试创建的线程组，所以线程数不多）
- 创建 HTTP 请求。填写正确的服务器ip、端口以及url。
- 添加察看结果树。察看结果树是 JMeter 的一个监听器元件，用于查看请求和响应的详细信息。
- 添加聚合报告。聚合报告是另一种监听器元件，用于提供测试结果的摘要和统计数据。
3. 测试结果
3.1 登录接口同时进行1000请求
3.2 登录接口请求量达到8000
- 现象：
- 出现异常并且响应速度变慢
- 异常原因分析：
- 查看分析结果数中请求异常的相应数据和生成的聚合报告。请求遇到了java.net.SocketException 异常，具体错误信息是 "Socket closed"，即在尝试发送请求时，底层的套接字连接被关闭了。可能是服务器负载过高，主动关闭了一些连接以缓解压力。
3.3运动员排名接口请求量为2000
- 现象：
- 未出现异常，但响应速度明显比登录接口慢
- 原因分析
- 运动员排名接口需要执行复杂的数据库查询且需要连接用户表与运动员表来获取数据，这可能会导致性能下降。
- 返回数据量较大，增加网络传输时间，尤其是在大量并发请求的情况下。
- 数据库服务器可能因为大量的并发查询而变得缓慢。
4. 改进思路
- 引入缓存机制，如Redis，减少对数据库的直接访问。
- 对热点数据进行缓存，减少数据库查询。
5. 百万级压力测试
- 对登录接口进行了百万级压力测试
- 测试结果
...全文
请发表友善的回复…
发表回复
