[T.17] 团队项目：Beta 阶段项目展示

亮点

分工

姓名	分工	说明
饶晨烜	后端+运维	负责聊天系统核心功能和文件存储功能开发，服务器和Web端部署
高子贺	Web端+后端	管理员后端接口开发，独立负责管理员网页端开发
安琦	后端	负责聊天系统开发，组队模块优化
袁耀武	小程序端	微信小程序聊天功能开发，负责微信小程序发布，功能优化
丁子航	小程序端+Web端	微信小程序功能优化和页面美化，官网开发
张珺强	小程序端	微信小程序功能优化和页面美化

典型用户场景

场景1：

• 用户：电子信息学院大三同学小A

• 需求：寒假需要招募队友参加美赛

• 解决方案：通过该小程序，在竞赛板块下发起组队

场景2：

• 用户：计算机学院大三同学小B

• 需求：需要招募精通后端的同学一起完成软工开发

• 解决方案：通过该小程序，在课程板块下发起组队

场景3：

• 用户：计算机学院大三同学小C

• 需求：需要招募伙伴一起踢足球

• 解决方案：通过该小程序，在生活板块下发起组队

场景4：

• 用户：经管学院大三同学小D

• 需求：小D想要通过手机微信小程序查看自己某天某课程有无缺勤

• 解决方案：小D可以在用户中心界面点击签到记录从而进入对应页面查看自己的签到记录

场景5：

• 用户：电子信息学院大三同学小F

• 需求：小F想加入某个队伍，并且想先和队伍创建者了解队伍成员情况

• 解决方案：小F可以在队伍界面点击队伍创建者头像并添加其为联系人，之后在联系人界面进行聊天

场景6：

• 用户：电子信息学院大三同学小G

• 需求：小G通过课程板块组好队后，希望能与队友建群，方便联系

• 解决方案：小G可以通知队友一起在队伍界面发起聊天，然后在聊天界面交流，该界面支持分享文本，图片，队伍等

场景7：

• 用户：电子信息学院大三同学小H

• 需求：小H是某队伍的创建者，希望将该队伍邀请给好友AA

• 解决方案：小H在队伍界面点击分享图标，然后选择联系人并进行分享

场景8：

• 用户：计算机学院大三同学小I

• 需求：小I想要通过手机微信小程序预约抢博雅课程

• 解决方案：小I可以在用户中心界面下点击博雅助手进入博雅抢课页面实现抢博雅

场景9：

• 用户：计算机学院大三同学小J

• 需求：小J想要通过手机微信小程序给技术人员提出改善建议以提升自己的体验

• 解决方案：小J可以在用户中心界面下点击反馈问题输入反馈内容，反馈主题等等信息后提交

杀手级功能

实时聊天功能

用户在使用组队功能时，需跳转至微信外部沟通，导致：

1. 体验割裂：频繁切换应用降低操作效率；

2. 信息丢失：微信聊天记录无法与组队动态关联；

3. 功能局限：无法直接分享队伍。

因此我们在软件内部加入了实时的全场景聊天系统，实现闭环社交：

1. 用户申请入队时，可一键发起与创建者的私聊，便于更好地选择队伍

2. 成功入队后，用户自动加入队伍专属聊天室，成员可随时交流。

3. 聊天支持上传图片和分享队伍

组队绑定课表

用户在发起组队时，可以跳转至课程打卡页面并绑定一门课程。在使用搜索功能时，软件会推荐所绑定课程与搜索关键词相似的组队，实现更加合理的搜索。

系统发布

我们通过在微信群内部宣传的方式推广小程序，积累用户

以下是用户数目统计与某一时间的在线记录：

软件工程质量

后端开发规范

• 微服务：使用配置中心，区分不同成员的开发环境与生产环境。所有的身份校验、鉴权、负载均衡都在网关完成，业务服务内部通过请求头传递当前用户信息，各个微服务之间通过OpenFeign和消息队列相互调用。

• 数据库使用：禁止在Service层直接暴露SQL，复杂查询使用QueryDSL动态SQL构建。同时Redis缓存Key使用统一前缀格式。

• 日志记录：使用MDC记录所有请求记录。

• 代码风格：使用静态代码分析工具确保代码符合规范，且提交代码前必须通过Checkstyle检查。

前端开发规范

• API 封装规范：在https.js统一封装API并Promise 化 API

• VUE文件结构顺序规范：先template再script最后style

• 代码风格：符合eslint规范

测试规范

• 后端单元测试：使用Mockito模拟依赖，要求核心业务测试覆盖率大于80%。

• 后端接口测试：Postman结合自动化测试脚本

• 前端测试：采用Mock测试，以可控的方式模拟真实的对象行为

CI/CD流程

• 当后端代码提交到dev分支后，触发CI/CD流程，将代码打包成Docker镜像并推送到镜像仓库。之后，服务器从仓库中拉取镜像，启动容器完成部署过程。

• 当Web端代码提交后，会触发CI/CD流程，将代码打包成dist文件后上传到服务器中nginx配置的路径下，并重启nginx，完成部署过程。

项目与团队总结

成员简介

成员	介绍	个人博客地址
饶晨烜	我是魔精员工	https://www.cnblogs.com/cx-rao
高子贺	你知道我要说什么	https://www.cnblogs.com/aron00123
安琦	可以写一辈子软件工程吗？	https://www.cnblogs.com/bbbbbbbbb
袁耀武	Always keep a beginner's mind!	https://www.cnblogs.com/saltfishDreamer
丁子航	我在软工里，感觉很平静	https://www.cnblogs.com/DingZihang
张珺强	哦耶，坚坚的果！	https://www.cnblogs.com/oyjgq

项目管理

我们采用github进行代码管理，团队合作开发，利用git status命令解决冲突。

项目整体采用前后端分离和微服务的思想进行开发，小组成员在确定接口后独立开发，定期进行系统联调推进项目进展。

1. 通过Apifox进行接口管理和功能测试，进行前后端和微服务内部联调

2. 通过飞书进行项目进度管理，分配开发任务，进行Bug管理和修复

在完成代码后推送到仓库后，通过Github的workflow触发CI/CD，进行自动化测试，然后打包为Docker镜像推送到仓库中，服务器拉取镜像启动容器，提高交付效率。

后端管理：

我们配置了两套环境：开发环境dev和生产环境prod，服务器同时运行两套环境并进行隔离。

主分支main用于生产环境，所有提交到main的代码都会构建并部署到生产环境。开发者不允许直接提交代码到main分支，只可以从dev上发起PR将代码合并到main上。

同时，用户端和管理员端统一开发，通过接口的url区分，所有专供管理员使用的接口都必须以/admin开头，进行统一的身份校验。

对于开发环境，请求的baseUrl为https://joinup.org.cn/api-dev ；生产环境，请求的baseUrl为 https://joinup.org.cn/api 。

前端管理：

前端采用HBuilder+微信开发者工具进行开发，开发时使用开发环境api，正式发布时改用生产环境api。

任务与进度管理

• 所有任务拆分成小块登记在飞书中，单个任务分为待办、进行中、已完成三种状态，并实时更新。

• 每项任务明确负责人、截止时间、关联分支，方便跟踪与协作。

• 每周召开多次会议，回顾进度，讨论当前难点，并安排接下来的任务。

• 会议负责人整理会议内容并记录在会议文档中，确保信息同步。

相较于alpha阶段，我们的任务分配更加明确，任务跟踪更加实时化。

分工协作

角色划分

我们采取了按模块+按角色结合分工的方式：

• 组长：任务分配、进度管理、需求收集与协调。

• 后端开发：使用Spring Boot开发，处理业务逻辑、数据库、用户权限等内容

• 前端开发：编写页面（登录、队伍列表、组队页面等），负责UI与后端数据对接

• 管理端开发：编写管理员后端接口与网页端部分，并与后端开发人员写作

经验教训

• 按功能模块分工提高效率：每人负责一块完整功能并对自己模块全流程负责，降低了不同人员之间的依赖程度，实现了并行开发

• 每周例会同步进度与问题：每周至少两次会议，分享进度、解决冲突。

• 代码合并遵循流程：所有成员通过分支开发，提交PR，由组长进行合并，避免直接push到主分支。

沟通和对接

日常沟通：使用微信/QQ 群

• 每位成员加入开发群，日常问题随时提问、答复。

• 临时协商、小问题迅速解决，保证开发节奏。

每周固定会议

每周至少两次例会，由当周负责人主持并记录，内容包括：

• 回顾本周完成内容

• 讨论技术实现方案

• 确认下周任务分配

前后端接口对接

使用ApiFox：后端统一说明接口url、请求参数、返回格式等信息，前端参考文档对接接口，减少沟通成本。

图片记录

会议记录示例：

接口文档示例：

时间/质量/资源的平衡

我们采用了以下策略：

1. 任务优先级划分，集中资源解决关键模块：按功能划分出“核心必须完成的功能”和“可选优化项”，优先保障主线流程不受影响，在此基础上利用空闲时间不断优化。

2. 合理制定时间表，按阶段推进：分阶段推进，每阶段确定清晰的目标

3. 按人所长分工：成员根据技术特长分配任务，减少协作成本，提高开发效率。

4. 质量把控机制：每个模块开发完毕必须经过Code Review审查才能合并主分支

实际进展

燃尽图

燃尽图对状态的反映

• 在每周开始前，团队将目标拆解为多个子任务并记录，每个任务由执行者估算工作量。

• 每一天开始时任务负责人更新任务完成状态

团队贡献

beta阶段贡献分如下：

成员	基础分	文档加分	开发加分	总分	具体贡献
饶晨烜	30	0	38.25	68.25	独立负责搭建开发、测试、生产环境的CI/CD；独立负责服务器日常维护和项目部署；完成后端微服务框架搭建，开发系统主要功能，编写接口文档；完成部分PM工作并组织系统联调，解决Bug，负责搭建聊天功能
安琦	30	8	8.375	46.375	聊天功能开发，队伍服务优化，课上展示
高子贺	30	0	18.15	48.15	独立完成管理员Web端开发；独立完成管理员后端接口开发。
袁耀武	30	2	20.625	52.625	聊天功能，联系人功能开发，功能优化，图像存储等问题修复
丁子航	30	10	10.7	50.7	官网界面+alpha阶段bug修复+封面功能实现+展示页面重构+新的路由设计
张珺强	30	0	3.9	33.9	本地token定时刷新+兴趣技术模块+队伍绑定课程+点击队伍数跳转队伍列表

结合alpha阶段，总贡献分如下：

成员	Alpha 2/3	Beta 1/3	总分
饶晨烜	77.5	68.25	74
安琦	50.5	46.375	49.125
高子贺	55	48.15	52.72
袁耀武	50	52.625	51.275
丁子航	38.5	50.7	42.58
张珺强	28.5	33.9	30.3

用户场景

预期用户场景

这一部分已经在亮点部分进行过清晰展示

是否满足所有典型场景

项目发布后，我们基本覆盖并满足了大多数典型使用场景，尤其是围绕“组队找人 + 沟通协作”的主流程，但也确实存在某些场景尚未完全覆盖。在组队后的任务协作部分，受限于开发时间，我们仅支持聊天功能，缺少像任务板、进度跟踪等“项目管理”类功能。

用户关于功能改进的反馈

通过软件的反馈功能，我们收集到了一部分用户对功能改进的建议，包括以下内容：

• 增加消息撤回功能

• 增加组队后对任务的跟踪功能

• 优化队伍浏览界面的推荐

用户日活

以6.10日为例，用户核心数据如下：

日访问人数如下：

日访问页面数如下：

日新增用户数如下：

特色功能

杀手级功能

这一部分已经在亮点部分进行了详尽介绍

竞品未囊括该功能的原因

产品定位偏向“工具”而非“社交平台”

多数组队类竞品功能集中在找人/建队/发布需求，并没有真正关注后续沟通效率。同时实时沟通被认为是微信、QQ 的职责，因此选择跳转外部平台而非自行实现

实时通信技术门槛高

实现即时通讯功能需要掌握WebSocket、消息队列、前后端状态同步等技术，对团队的后端架构设计、消息推送服务提出更高要求。竞品出于开发难度与稳定性考量，通常选择放弃或使用外部 SDK 接入，难以深度整合。

产品定位不够精确

其他竞品用户面较广，作为面对北航学生提供服务的平台，本软件可以利用这一性质提供更加精准的服务，例如课程组队绑定课表

团队优势与评价

我们团队有以下优势：

• 技术积累与团队配合良好

• 架构规划明确，提前预留扩展性：在项目开发初期就考虑了聊天部分，并进行了初步模块化设计

• 差异化创新：我们通过用户课表绑定，引入简单的关键词匹配机制，提升了搜索匹配度与相关性，这在课程项目组队、校内活动中尤其实用，准确命中用户实际需求场景。

我们团队认为，这些功能能够满足用户需求。

软件工程质量

项目文档

本项目全程有详尽的文档记录，分别包括技术文档，部署文档和需求文档

设计文档包括了系统设计和数据库设计，例如：

• 系统架构图

• 接口设计文档

• 数据库设计图

部署文档包括以下内容：

• 前后端本地运行、测试环境部署说明

• 所需依赖、环境变量配置说明

需求文档包括以下内容：

• 说明项目的功能目标、用户角色、使用场景等。

• 描述了用户登录、发起组队、搜索队伍、消息通知等核心功能。

代码规范

后端分别遵循以下规范：

• 代码风格规范：统一使用阿里Java开发命名规范，并使用IDE插件统一格式化。

• 注释规范：所有公共方法使用JavaDoc注释。

• 日志规范：统一使用MDC记录所有请求历史。

前端分别遵循以下规范：

• API 封装规范：在https.js统一封装API并Promise 化 API

• VUE文件结构顺序规范：先template再script最后style

• 代码风格：符合eslint规范

• 项目结构规范：按照功能模块进行目录划分。

项目是否出现过代码混乱、无注释、无文档的问题？

在项目早期开发阶段，确实存在一定程度的代码混乱和文档不完善的问题。部分模块在原型阶段缺乏注释，难以理解，同时部分接口前后端在对接时出现了不一致问题。但随着开发进程推进，这些问题都注意得到了解决。

明年的同学继续开发，会不会出现“代码混乱、没有文档”的抱怨？

不会，我们提供了详细的文档说明，只要仔细阅读文档就不会遇到这种问题

新同学在新机器上能否成功运行项目？

能，我们在文档中分别给出了前后端详尽的部署过程

单元测试

后端

测试用例范围

• 所有业务逻辑方法（Service 层）

• 对外接口转换与校验（Controller 层）

• 公共工具类、DTO/VO 转换与校验逻辑

代码覆盖率

要求测试用例覆盖率高于80%

测试策略

1. 模拟隔离

   1. 使用 Mockito 完全模拟外部依赖

   2. 对数据库层测试可选用 H2 内存库，但必须在隔离模式下执行

2. 场景覆盖

   1. 正常场景：关键流程、常见数据输入

   2. 边界场景：空集合、最大/最小值、字符串长度极限

   3. 异常场景：模拟依赖抛出异常、参数校验不通过

3. 断言规范

   1. 使用 AssertJ 进行链式断言，保证可读性

   2. 校验返回值、状态码、异常类型与消息均符合预期

   3. 对关键交互调用使用 verify(...) 检验调用次数及参数

测试工具与环境

• 测试框架：JUnit 5

• 模拟框架：Mockito

• Spring 支持：spring-boot-test

• 断言库：AssertJ

• 覆盖率工具：JaCoCo（目标 ≥ 80%）

• 构建工具：Maven

• CI 平台：GitHub Actions

前端

测试用例范围：页面功能逻辑测试

测试策略：

1. mock模拟后端，完成api交互

2. 模仿用户体验界面，完成基本的功能测试

测试工具与环境：

在不同层面上（Web层、Service层、Data层）进行了单元测试，并使用Mock对象和环境变量来隔离测试，避免对外部服务或数据库的依赖。

• 构建工具：HBuilder+Uniapp+微信开发者工具

CI/CD

我们为后端配置了生产环境和开发环境两套CI/CD工作流。

在dev(开发环境)分支有新的提交后，会触发下面的workflow，构建各个微服务的Docker镜像并推送到镜像仓库中，服务器从镜像仓库中拉取镜像，并通过docker-compose启动所有微服务。

在main(生产环境)分支有新的merge后，会触发下面的workflow，与dev分支类似，区别在于二者使用不同的数据库，redis，消息队列，nacos命名空间。对于这些中间件配置等敏感信息，我们不允许提交到仓库中，需要在配置文件中通过环境变量加载。

在采用CI/CD后，Web端和后端的开发效率得到了极大提升，运维同学配置好整体CI/CD流程和服务器后，开发同学只要提交代码就可以自动完成代码编译、构建镜像上传到服务器、启动容器这一复杂过程。

在beta开发阶段，我们的项目使用了以下三个仓库：

• 微信小程序仓库：https://github.com/YuXiaosen0/joinup

• 服务器仓库：https://github.com/XuanxuanRao/joinup-server

• 管理员Web端仓库：https://github.com/Aron00123/joinup-admin-web

main分支用于生产和发布，是正在线上运行的版本，只允许从dev分支合并；dev分支是开发环境下的最新版本，对于简单bug的修复和小功能的新增，允许直接提交到dev分支上，如果涉及到添加新的功能模块，需要进行大量修改才能修复的bug，必须迁出feature分支用于实现新功能，迁出fix分支用于bug修复。

经验和教训

• 版本控制与协作流程极其重要：通过Git + 分支策略，我们避免了多人修改同一文件导致的冲突，同时PR的使用提高了代码质量，避免了在生产环境触发较大的bug

• 提前规划接口：在开发时需要提前约定好后端接口格式，并使用Apifox自动生成预览，从而提高前后端协作效率。

• 引入自动化工具：引入CI/CD流程后，每次push操作都能自动构建和测试，快速发现错误。