第二次团队作业

项目评分标准

团队名称：洛珈山下

团队人员姓名： 齐思贤， 彭文昊 ，袁镇清 ，谢嘉骏 ，张嘉铭 ，林旭坚 ，阿丽亚·阿不来海提

壹. 需求规格说明书（25 +5 分）

（壹）面向用户分析和功能分析

一、核心微服务划分（按领域驱动设计 DDD）

1. 用户服务（User Service）

  • 核心职责：用户全生命周期管理

  • 功能模块

    ：

    • 用户注册 / 登录、Token 管理（JWT 生成与验证）
    • 用户信息管理（个人资料等）
    • 权限控制（普通用户 / 管理员角色）

  • 数据存储：用户表（user）、用户权限表（user_role）

  • 对外接口

    ：

    • POST /api/v1/users/register（注册）
    • POST /api/v1/users/login（登录）
    • GET /api/v1/users/{id}（查询用户信息）

2. 商户服务（Merchant Service）

  • 核心职责：校园内商户（食堂、教学楼、宿舍等）的信息管理

  • 功能模块

    ：

    • 商户基础信息维护（名称、地址、分类、营业时间、图片等）
    • 商户创建 / 审核（用户提交后需管理员审核，避免重复）
    • 商户标签管理（如 “性价比高”“24 小时开放”）

  • 数据存储：商户表（merchant）

  • 对外接口

    ：

    • POST /api/v1/merchants（创建商户，需审核）
    • GET /api/v1/merchants?category={id}（按分类查询商户）
    • GET /api/v1/merchants/{id}（查询商户详情）

3. 点评服务（Review Service）

  • 核心职责：用户对商户的点评及互动（回复、点赞）

  • 功能模块

    ：

    • 点评发布 / 编辑 / 删除（含评分、文字内容、图片）
    • 点评回复（用户间互动）
    • 点评点赞 / 取消点赞
    • 点评排序（最新 / 最热 / 评分优先）

  • 数据存储：点评表（review）、回复表（reply）、点赞表（review_like）

  • 对外接口

    ：

    • POST /api/v1/reviews（发布点评）
    • GET /api/v1/merchants/{id}/reviews（查询商户的点评列表）
    • POST /api/v1/reviews/{id}/like（点赞点评）

4. 收藏服务（Collection Service）

  • 核心职责：用户对商户的收藏管理

  • 功能模块

    ：

    • 收藏 / 取消收藏商户
    • 查询用户收藏列表
    • 统计商户被收藏次数

  • 数据存储：用户收藏表（collection）

  • 对外接口

    ：

    • POST /api/v1/collections（收藏商户）
    • GET /api/v1/users/{id}/collections（查询用户收藏）

5. 搜索服务（Search Service）

  • 核心职责：商户和点评的高效检索

  • 功能模块

    ：

    • 商户搜索（按名称、地址、标签模糊查询）
    • 点评搜索（按关键词、评分范围筛选）
    • 搜索结果排序（相关性 / 评分 / 热度）

  • 技术依赖：集成 Elasticsearch 实现全文检索，定期从商户 / 点评服务同步数据

  • 对外接口

    ：

    • GET /api/v1/search/merchants?keyword={str}（搜索商户）
    • GET /api/v1/search/reviews?keyword={str}（搜索点评）

6. 通知服务（Notification Service）

  • 核心职责：用户互动消息推送

  • 功能模块

    ：

    • 点评被回复通知
    • 点赞通知
    • 系统公告（如商户审核结果）

  • 实现方式：支持站内消息（数据库存储）

  • 对外接口

    ：

    • GET /api/v1/notifications（查询未读通知）
    • PUT /api/v1/notifications/{id}/read（标记通知为已读）

二、支撑性服务（基础设施）

1. 网关服务（API Gateway）

  • 作用：统一入口、路由转发、认证鉴权、限流熔断

  • 技术选型：Go-Zero、Spring Cloud Gateway 或 Kong

  • 核心功能

    ：

    • 将客户端请求路由到对应微服务（如 /api/v1/users → 用户服务）
    • 统一验证 JWT Token，无需各服务重复实现
    • 限制单 IP 访问频率，防止恶意请求

2. 配置中心（Config Server）

  • 作用：集中管理各服务配置（数据库地址、第三方 API 密钥等）
  • 技术选型：Nacos、Apollo
  • 优势：动态更新配置（如修改数据库连接池大小），无需重启服务

3. 注册中心（Registry）

  • 作用：服务注册与发现，解决微服务间通信地址动态变化问题

  • 技术选型：Eureka、Consul、Nacos

  • 工作流程：服务启动时注册到中心，调用方通过中心获取目标服务地址

三、服务间通信方式

  1. 同步通信：
    • 采用 RESTful API（HTTP/HTTPS）或 gRPC（高性能场景，如搜索服务调用商户服务）。
    • 例：网关调用用户服务验证 Token，点评服务调用商户服务获取商户名称。
  2. 异步通信：
    • 基于消息队列（Kafka、RabbitMQ）实现解耦，如：
      • 点评发布后，发送消息到队列，商户服务消费消息并更新评分。
      • 用户收藏商户后，发送消息到队列，通知服务消费并记录行为。

（贰）：技术需求

数据库：数据库使用mysql+redis；
后端：go语言：go使用gin+gorm+kratos；
后端：C语言：Visual Studio 2017 和VS code C++等；
前端：html，css，js以及vue等；
部署：部署使用docker，k8s等。

贰. 给出预期的用户数量（3 分）

学生用户：根据公开信息，广东工业大学本科生人数有40,018人；按照招生人数统计，大学城每年的本科录取人数是5684人，不计转校区和延毕的学生，大学城总本科生人数为22,736人，和根据大学总的预估数量级相同。本人考虑10%的漏报和转校区，延毕等小概率事件，按照大学城本科生人数约为25,000人。
本系统会先在广东工业大学大学城校区的本科生中上线，预计本年度使用人数是大学城校区的本科生人数的十分之一，也就总学生用户数是2,500人。并发用户数量按照总用户数量的10%为估计，也就是大约有250人作为并发用户，我们为了增加系统的鲁棒性，我们计划有300人次并发学生用户。

参考网页
https://zsb.gdut.edu.cn/xxcx/zsjh1/zsjhzb1.htm
https://www.gdut.edu.cn/xxgk/tjsj.htm#

商家用户：按照初期推广目标（二食堂一楼和三食堂一楼），商铺数量不足40家，再加一些25%的鲁棒性做估计，一共总商家用户数量定成50。因为这些商家会同时在吃饭时间上营业上营业，并发用户规模和总用户规模相同，均为50家。

因此，预期的用户数量包含两个层面：

  • 总用户数量：预计系统在本年度年内积累的总注册学生用户数将达到 2,500人，商家用户达到50家。这主要用于评估数据存储容量。

  • 并发用户数量：预计业务高峰期的平均并发学生用户数约为 300人，商家用户达到50家。这主要用于评估系统的实时处理能力和服务器资源。

叁. 阐述系统的（2 * 3 分）

一、真实性保障（2分）：从源头杜绝虚假，守住核心信任

对学生：采用统一身份认证，仅在校学生可参与评价，从用户层面过滤水军和外部虚假账号。
双重内容审核机制：本应用采用自动拦截手段，拦截辱骂、广告类违规内容；同时采用人工复核短时间大量好评等疑似虚假评价。
对商家：商家差评申诉需提供整改证明，平台审核通过才会处理，避免恶意差评或无效申诉，确保评价可信度。
平台本身：无商业化资本干预，运营独立自主，不因投资方压力或商业合作需求操纵评价展示、排序或内容，保障所有评价数据的原始与客观。

二、可用性设计（2分）：贴合校园场景，操作高效无门槛

客户（学生）端：筛选维度精准匹配校园需求（如具体饭堂楼层、校园专属标签），搜索结果附带步行距离、排队提示，决策效率直接提升；核心功能（评价、收藏、查榜单）操作路径短，图文 / 视频评价形式符合学生使用习惯。
商家端：入驻审核需校园相关证明，流程规范且明确；评价互动、数据查看功能直观，无需复杂操作就能获取核心改进方向，适配校园商家的使用场景。
平台端：对接校方后勤同步官方信息，既简化信息维护成本，又提升平台权威性；认证与审核流程自动化 + 人工结合，运营效率更高。

三、价值所在（2分）：三方共赢，构建良性校园消费生态

对学生：解决 “不知道吃什么、怕踩雷” 的消费痛点，通过真实评价、精准筛选和特色榜单，节省决策时间，提升校园消费体验。
对商家：免费获取学生真实反馈和核心数据，明确服务改进方向（如排队、性价比问题）；通过评价互动树立良好形象，吸引更多学生消费。
对校园：搭建学生与商家、校方的沟通桥梁，推动校园消费服务标准化升级，形成 “学生省心、商家改进、校园有序” 的良性循环。

肆. 给出团队项目的码云链接（3 分）

码云链接：
https://gitee.com/JacketH/Campus-Review-System/issues
Github仓库：
https://github.com/Under-Luojia/Campus-Review-System

伍. 制定团队计划

（壹） 将团队的任务计划添加到码云的团队项目Issues里面（5 分）

参考码云和github仓库

（贰） 在博客中提供码云的团队项目Issues截图（2 分）

940bd0e0547a335b3690e2e97edac5f

（叁）给出团队项目的时间安排表（8 分）

1. 需要给出原有安排（3 分）

周次 内容
第9周 1. 团队组队、团队博客
2. 团队介绍、成员展示、角色分配、选题确定
3. 制定团队计划安排，团队贡献分的规定
第10周 1. 需求规格说明书
2. 原型设计，队员估计任务难度并学习必要的技术
3. 编码规范完成、平台环境搭建完成、初步架构搭建
第11周 1. 原型改进（给目标用户展现原型，并进一步理解需求）
2. 架构设计，WBS, 团队成员估计各自任务所需时间
3. 测试计划
第12、13周 1. 团队项目Alpha任务分配计划
2. 连续7天的Alpha敏捷冲刺，7篇每日Scrum Meeting博客+代码提交
第14周 1. 用户反馈+测试计划改进
2. 团队Alpha阶段个人总结
3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理
第15周 1. 团队项目Alpha博客：事后分析

原有安排的问题：

  1. 时间节点不明确：原先的计划安排只标注了周次，缺乏具体的起止日期。

  2. 任务粒度较粗：开发两个模块的任务合并在一起，缺乏具体的执行步骤。

  3. 缺乏阶段性划分：没有清晰的阶段划分和里程碑。

4.测试环节薄弱：测试计划安排不够充分。

5.本团队因为存在大量成员比赛，存在一定的时间延误。

（原有的时间安排很不详细，需要更详细的安排）

2. 校正后的安排（3 分）

（只进行分析之后几周）

阶段 起始日期 结束日期 持续时间 周数（按照广工教学周编号） 主要内容（里程碑）
需求分析与规划 2025-11-12 2025-11-18 1周 第11周 需求文档完成、项目启动会议
系统设计
开发Sprint 1（核心模块）		 2025-11-19 2025-11-25 1周 第12周 架构图、API文档、数据库设计完成，
用户下单、商户服务基本实现
开发Sprint 2（互动模块）
测试 Sprint 1（核心模块）		 2025-11-26 2025-12-02 1周 第13周 点评服务、收藏服务、搜索服务集成基本实现
用户下单、商户服务调试完成
测试Sprint 2（互动模块）
集成测试与优化		 2025-12-03 2025-12-09 1周 第14周 单元/集成测试完成、性能优化
点评服务、收藏服务、搜索服务集成基调试完成
部署与上线 2025-12-10 2025-12-16 1周 第15周 系统上线、用户手册、维护计划

3. 矫正计算方法（2 分）

1.因组员比赛任务压力大，导致任务出现延期
2.学习成本：新技术学习需要额外时间缓冲
因此：
原计划剩余时间：5周（11-15周）
有效开发时间：5周 × 70% = 3.5周（考虑比赛和学习影响）

需求分析：0.7周（原计划1周 × 70%）
系统设计：0.7周
开发阶段：1.4周（2个Sprint × 0.7周）
测试阶段：1.4周（2个Sprint × 0.7周）（和开发并行，不计算）
部署上线：0.7周
总计：3.5周（与有效时间匹配）

陆. 其他

（壹） 排版（3 分）

(略，已经进行排版，格式如下）

标题使用情况

1.总标题用一级标题；
2.段落标题使用二级标题（每个小节使用横线分割）；
3.必须提及的字段落会使用三级标题；
4.自己额外加的字段落标题采用四级标题。

引用和表格的使用

本团队在合适的地方使用引用和表格

（贰） 团队的分工（5 分）

见下小节，

（叁） 每个人完成的情况（2 分）

学号 姓名 任务 完成情况
3123003122 齐思贤 制作博客，整合工作 已完成
3123004192 彭文昊 建立github仓库，组建团队 已完成
3123002353 袁镇清 完善技术知识体系（进行相应技术栈的学习） 已完成
3123002127 谢嘉骏 拓展技术边界，探索技术疆域 已完成
31230042203 张嘉铭 完成部分文字工作 已完成
3123004185 林旭坚 划分后端功能工作，完成API接口 已完成
3223004639 阿丽亚 对计算机更新换代，以适配校园点评系统软件 已完成

（肆） 每个人的感想（10 分）

齐思贤

这次软工小组作业让我深刻体会到团队协作的力量。我这次写篇文章，如果没有队友的鼓励和帮助，我是无法完成的。这次作业不仅锻炼了技术能力，更让我学会了如何与队友沟通。

彭文昊

这次软工小组作业让我深刻体会到团队协作的力量。从需求分析到代码实现，每个环节都需要充分沟通、互相配合。过程中虽遇到过分歧，但通过协商找到了最优解。当最终成果落地时，那种集体成就感的喜悦远超个人完成作业的满足。这次实践不仅锻炼了技术能力，更让我学会了如何在团队中高效工作。

袁镇清

这次软工小组任务让我真切感受到了团队协作的价值。从方案构思到动手实践，每个步骤都离不开充分沟通与默契配合。过程中难免出现思路碰撞，但我们通过坦诚交流凝聚了共识。那种共同奋斗后的成就感，远非独自完成任务能比拟。这次经历不仅提升了专业技能，更让我领悟到在团队中分工协作、互补共赢的重要性。

谢嘉骏

项目刚开始，我主要处在学习阶段，正在熟悉我们项目要用到的一些技术和工具。通过和组员们的沟通，我对我们的目标和自己的任务越来越清晰了。能加入这样一个团队我感到很幸运，期待之后能和大家一起把项目做好。

张嘉铭

我们分工明确，前端打磨界面、后端搭建逻辑、测试排查问题，围绕学生需求推进功能。遇到技术卡点时，大家一起讨论解决，既提升了实操能力，也懂了协作的重要性。看着系统从想法落地，深刻体会到“分工协作+用户导向”才是项目成功的关键。

林旭坚

约定后端开发的共同规范与格式，梳理各个模块接口，提高团队开发效率，后续将加快接口开发进度。

阿里亚

参与这次学术科研立项小组项目，让我对团队协作的意义有了更深刻的认知。从选题调研、文献梳理到方案设计、数据采集，每个步骤都需要成员发挥专业所长、紧密配合。过程中，我们曾因研究方向的界定产生分歧，也因实验数据不理想陷入瓶颈，但通过充分讨论、理性分析，最终找到了最优解决方案。当项目顺利结题并获得认可时，那份集体努力换来的喜悦与成就感，远比个人完成任务更加强烈。这次实践不仅提升了我的科研能力和问题解决能力，更让我学会了倾听他人意见、合理分工协作，懂得了团队的合力才能攻克更大的挑战。

posted @ 2025-11-12 01:26  _NXX  阅读(19)  评论(0)    收藏  举报