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

HelloWorld 2024-06-13 23:24:12

项目与团队亮点

项目	内容
这个作业属于哪个课程	2024年北航敏捷软件工程
这个作业的要求在哪里	[T.17] 团队项目：Beta 阶段项目展示
我们在这个课程的目标是	学习敏捷开发和软件工程
这个作业在哪个具体方面帮助我们实现目标	展示Beta阶段成果

语雀展示文档，gif图片需要在语雀中显示，最新内容也在语雀文档中。

团队成员与分工简介，并说明团队是如何进行项目管理的。

姓名	前后端	主要负责工作
孙玉粮	前端	前端美化，房间和房间详情页面UI设计及前后端对接
谢卓然	前端	前端美化，聊天功能，导航栏设计，前端websocket对接，排版bug修复，机动补充
曹伯炜	测试	前端匹配动画，http请求所有接口测试，websocket请求所有接口测试并生成行覆盖率，oj更新题库,验题
彭莘	前端	前端美化，比赛界面设计及前后端对接
陈俊霖	后端	后端WebSocket对接，局内游戏机制设计与实现。协助测试，更新题库，验题。
贺春瑞	后端	后端基础架构的搭建
葛卓成	后端	oj管理，提供后端接口，更新题库，验题，后端docker部署，docker容器内存管理。

项目管理

开发-github

项目进度管理-github projects+自动生成燃尽图，语雀管理

测试：
开发时测试
后端开发时采用ApiFox本地部署模拟测试。
前端开发时采用服务器进行测试。
单元测试：后端使用junit对controller层http请求和websocket请求进行单元测试。
http请求使用MockMvc模拟请求并采用数据库回滚方式对好友请求相关，游戏相关，广播消息和私聊消息相关，oj评测相关，房间相关以及登录注册相关功能进行多次测试。
websocket请求本地建立客户端类，模拟多个客户端实现多线程模拟请求，测试单人模式匹配请求，局内聊天请求，番茄道具功能，大逃杀，房间内开启游戏以及提交答案等多人相关功能以及个人登录，光标移动等个人相关功能。
集成测试：前后端一起进行功能上的集成测试。后端Controller和Service和数据库之间的自测通过junit进行。 Websocket关于比赛过程中的自测通过建立客户端类模拟真实环境进行本地测试。
内部功能测试：在发布前进行了一系列内部集体的功能测试。
压力测试：利用apache bench进行测试。
用户测试：通过玩家游玩来反馈bug
接口文档：语雀+ApiFox
websocket接口文档：WebSocket 接口约定
OJ接口文档：OJ API(写给后端看的)
http接口文档（apifox）：

例会：
半天集体线下开发为一次整体例会。
额外开发计入下一次机会进行讨论。

项目的典型用户场景，以及最终的软件如何满足该场景。

中小学电脑课

老师自定义上传题目到oj系统
gif图片
老师将上课任务分配给队员，组长根据题单创建房间，邀请组员参加游戏
添加房间.gif
组员进入游戏，组长开始游戏。游戏过程有同学ac题目，其他同学会根据ac数目进行扣血。
大逃杀功能.gif

学生在课程内容外进行游戏

同学在完成课程内容后，可以通过匹配功能，自定义参加大逃杀或单人模式
通过游戏来进行pk，获得喜悦。
项目的杀手级功能，与竞品相比最特色的功能展现。
项目的游戏性（丢番茄，血量，获胜&失败动画）
有趣的匹配动画和音效
新匹配动画.gif
胜利动画.gif
失败动画.gif
多种游戏模式：大逃杀&单人模式

房间组队功能

好友系统：添加好友，好友列表

自定义管理、导入题目功能

项目发布时团队做了哪些努力，实际活跃用户数据如何？

宣传：在2106，2206，2221水群进行宣传。
测试：开发过程及发布前，团队会对软件进行全面的测试，包括使用apiFox的接口测试和基于appeche的压力测试，确保软件质量和稳定性。
部署：配置服务器、数据库等。

docker部署后端，优点：

隔离性
Docker容器提供了进程级别的隔离，每个容器都有自己的文件系统、网络和进程空间。这样，即使一个容器被攻破，攻击者也难以影响其他容器或宿主系统。
最小化攻击面
通过Docker，应用可以被打包成只包含其运行所需的最小集合的库和工具，这减少了潜在的攻击面。比起传统的全系统部署，Docker容器更加轻量化和专用化。
快速修复和更新
Docker镜像可以快速构建和部署，允许快速修复安全漏洞并立即部署到生产环境中。使用Docker Compose等工具，可以轻松实现多容器应用的一键部署和升级。
一致性和可重复性
Docker镜像确保了开发、测试和生产环境的一致性。这种一致性使得安全性评估和测试更加可靠，因为所有环境下的应用运行都是相同的。

docker-compose.yml&Dockerfile&start.sh:

version: '3'
services:
  myBattle:
    image: hh
    environment:
      - JAVA_OPTS=-Xmx2g -Xms1g
    ports:
      - "9090:9090"
    deploy:
      resources:
        limits:
          memory: 7g
          cpus: '3.0'
    restart: always
=======================================================================================
FROM openjdk:22

WORKDIR /home/ubuntu

COPY . /home/ubuntu

EXPOSE 9090

CMD ["java", "-jar", "BattleByte.jar"]
=======================================================================================
cd /home/ubuntu/BattleByte-backend 
sudo docker build -t hh .
sudo docker login
sudo docker tag hh jeffery6666/battle_byte:latest
sudo docker push jeffery6666/battle_byte:latest
sudo docker stop myBattle && sudo docker rm myBattle
sudo docker compose up -d

反馈收集：创建金山共享文档收集bug信息，全部已修复

截止6月13日晚上，累积152名用户，开始了579场游戏。

团队代码的软件工程质量如何？如何用数据来证明？

通过语雀记录会议纪要、博客、开发信息集散等文档。
GitHub Issue记录具体的待开发工作并进行分工

github projects统计总体完成进度并生成燃尽图

压力测试

使用 apache bench 模拟 3500 路并发，15000个请求获取较大资源

请求平均等待时间34秒
服务器平均处理时间0.009秒

单元测试

测试结果总结如下：

部分行覆盖率情况如下：

websocket测试情况如下：

我们认为团队代码的软件工程质量较好。衡量代码质量的指标如下：

衡量质量提高：
- 代码质量指标：包括代码复杂度、代码覆盖率、bug 数量等。
- 用户满意度：通过收集用户的反馈和评论，了解他们对程序的整体体验和满意度。
- 性能指标：包括响应时间、吞吐量、资源利用率等
  为方便展示，请预留2-3分钟做项目的demo展示（或提前录制视频放在博客中）。

项目管理

团队成员的简介和个人博客地址。

成员	自我介绍	个人博客地址
曹伯炜	6系一哥们
孙玉粮	菜菜捞捞
谢卓然	理论挺多，实际挺摸
彭莘	不准摸鱼辣
葛卓成	前端转后端ing
贺春瑞	[离线请留言]
陈俊霖	布响丸辣	无

团队是如何进行项目管理的？相比于Alpha阶段有什么改进？

团队采用git进行项目管理，维护了frontend和backend两个仓库，并部署了CI。
相对于Alpha阶段，我们使用docker部署，提供了更加稳定的CI；对代码的PR更加严格。

团队的成员如何分工协作的？有什么经验教训？相比于Alpha阶段有什么改进？

分工协作：
基于项目的特殊性，我们使用前后端分离+oj的模式，根据技术栈等综合因素的考量，将开发人员分工进行，实现项目效益最大化。与此同时，项目的开发过程中涉及到需要无法均分的任务，对于这些特异化分工，我们选择交给指定的成员进行处理。例如我们有灵活的开发补位者，具有全栈的就开发能力，能沟通解决前后端开发和对接遇到的难题，解决不协调的问题。当然相伴的就是对于不是自己责任的部分的工作，呈现一种依赖状态。因此团队的并行化受到了一定的阻碍，这是因为有的层次必须先于另一个层次的实现，但是在初始化磨合完成后，并行的问题得到了一定解决。
经验教训：
全栈工程师非常重要（）
线下团队开发非常重要（）
每人负责一个相关模块，专研一个领域的知识可以提高团队效率。
改进：
相比Alpha阶段，调整了团队分工，由一名同学专门负责进行单元测试，整体任务划分和职能划分更加清晰。

团队成员如何沟通和对接的？有什么记录留存？

线下会议：集中开发提高效率
微信+微信电话会议：进行碎片化的、快速的沟通
GitHub：代码托管+issue管理（任务管理）+CI/CD（依托GitHub Actions）
Apifox: 语雀：文档、会议纪要、博客、开发信息管理

例会记录留存
Alpha阶段
第一次例会
 第二次例会
 第三次例会
 第四次例会
 第五次例会
 第六次例会
 第七次例会
Beta阶段
第一次例会
 第二次例会
 第三次例会
 第四次例会
 第五次例会
 第六次例会
 第七次例会
 第八次例会
 第九次例会

团队如何平衡时间/质量/资源争取如期完成任务的？

我们尽量做到将任务分配到个人，这样做能将工作具体落实，尽量做到有条不紊。由于开发时间有限，我们以需求为导向进行取舍，将更多的精力用于保证目标实现。两天集中开发一次，其余时间分开完成个人工作。

前期：前端完成基础组件，后端完成最小可用组件。后端本地apifox独立测试，前端利用后端cicd测试。
中期：完成前后端对接。
后期：测试+前后端两人成组对接进一步开发独立功能。
团队项目的实际进展如何

名字	角色	团队贡献分	具体的, 可衡量的, 可验证的贡献
陈俊霖	后端	50	负责websocket和设计、实现游戏机制，Beta阶段60+推送feat和fix。协助websocket测试，提交文档作业。oj更新题库，验题。
谢卓然	前端	50	新导航栏、匹配按钮、通知对话框等UI设计、SVG绘制、音效搜集和代码实现，websocket接口设计和前端实现，游戏机制对接，前端动效和结算动画。Beta阶段31次PR。
孙玉粮	前端	50	房间页面和房间详情页面设计和实现，前端20余次PR，总共近40次commit。
曹伯炜	测试	50	测试代码1200+行。前端匹配动画，http请求所有接口测试，websocket请求所有接口测试并生成行覆盖率，oj更新题库,验题
彭莘	前端	49	比赛界面设计和实现，前端仓库
贺春瑞	后端	49	基础架构的搭建，包括JWT+Shiro鉴权、好友系统等，89次PR，OJ更新题库，验题
葛卓成	后端	49	OJ系统维护，新增tag查询接口，更新题库，验题；后端docker部署到jvm虚拟机，上传到docker hub,配置容器防火墙；修修补补后端不知名bug，pr10+次，commit20+次

项目开发前的目标，预期的典型用户场景，预期的功能描述。

预期产品功能

单人模式&大逃杀模式：
○ 通过主页匹配进行联机
○ 用户进入比赛页面后，系统会提供题目描述、输入输出样例等信息。
○ 用户编写代码并提交，系统自动评测，并实时反馈评测结果与每个用户的答题情况，最后给出比赛胜负。
○ 可以根据题目完成情况评定来判断胜利。
○ 比赛结束后显示胜利&失败动画并自动跳转到首页
进度显示
○ 实时显示自己和对手的通过情况和代码编写情况。具体表现形式为编译器左侧的进度显示。
道具功能
○ 用户可以向对手投掷爱心番茄，可以干扰对手编程视线。
实时交流功能
○ 用户可以通过聊天框系统。
好友功能
○ 添加好友
○ 好友列表显示
房间功能
○ 添加房间，选中题目，题目预览
○ 加入/退出房间，房主开始匹配即可
历史记录功能
○ 用户可以点击导航栏上的生涯栏查看历史记录
规则
○ 用户可以点击导航栏上的规则界面查看使用规则

场景一：中小学电脑课

在一所中学的电脑课上，老师正在向一群初中生介绍编程的基础知识。有些学生对这些概念感到陌生，有些则显得很兴奋。老师决定通过一个编程实时对战游戏来帮助学生们更好地理解这些概念。
学生们被分成小组，每个小组拥有一台电脑。他们登录到游戏网站，开始进行有趣的编程比赛。随着一场场比赛的竞技，学生们逐渐掌握了编程的基本原理，比如循环、条件语句等。
在游戏中，学生们不仅学到了编程知识，还体验到了竞争的乐趣。他们与其他小组比赛，争夺最高分。通过这样的学习方式，学生们对编程产生了浓厚的兴趣，并且在游戏中享受到了学习的乐趣。

学生课后游戏

在学生放学回家之后，学生们可以通过代码对战平台与其他同学进行编程竞赛，提升编程技能。通过挑战不同的任务和对手，他们不仅能享受游戏乐趣，还能互相学习与进步。

项目发布的功能

首页

个人中心

好友列表

修改个人信息

修改密码

添加好友及搜索意向好友

查看好友主页

发送好友申请

匹配界面

游戏界面
可以看到自己的对手以及各自的血量和AC题目数量，并且可以查看对方进度

可以修改主题，语言，行高，字体大小

投掷爱心番茄（修改了覆盖面积）

为了鼓励大家获得胜利，我们给胜利和失败添加了特殊的页面和音效

评测返回结果

聊天功能

房间列表界面

房间内等待界面

创建房间界面（选择题目）

增加了历史记录的功能

项目发布时团队做了哪些努力来推广项目？

在2106，2206，2221水群和内部交流群进行宣传。

软件的日活跃用户量是否达到了预先定义的数量？如果没有达到，你们觉得可能是什么样的原因导致的？你们认为还有什么指标可以佐证你们的软件对用户“有用”？

截止6月13日晚上，累积152名用户，开始了579场游戏，日活跃用户量在10~20左右。没有完全达到预先设想的规模，可能的原因是该版本发布的时间与考期冲突，大家没有足够的时间来尝试。除此之外，用户反馈和游戏时长也可以用来展示软件的有用程度。

是否有用户在功能改进上有所反馈？可以提供用户反馈的截屏。

用户认为投掷番茄等游戏性功能很新颖有趣，不过对题目样例点数据的覆盖性，以及数据传输的加密程度提出质疑，还提出了前端由于不同电脑分辨率不同导致的部分显示问题

是否有用户在Bug上有所反馈？有什么样的bug？这是预料之中的还是没想到的？

详见bug反馈文档

特色功能

项目的杀手级功能，与竞品相比最特色的功能展现。

游戏性比较好，存在趣味道具爱心番茄。存在房间功能，聊天功能，好友系统等，实时交互性比较强。

思考一下竞品出于什么原因并没有囊括该特色功能，团队凭借什么样的优势实现了它？

分竞品主要功能在于提升编程技能没有侧重趣味性，以趣味性为主的竞品主要将趣味性体现在模式的数量和页面美观程度上，用户交互方式局限于表情和文字，尚未开发出道具功能。

团队成员对这些功能的自我评价如何，是否达到了预期目标，为什么？

觉得很好玩，砸西红柿挺解压的。

用户对这些功能的评价如何，是否认为这些功能富有特色，为什么？

软件工程质量

项目有完善的文档吗，是否有约定代码规范？

通过语雀记录会议纪要、博客、开发信息集散等文档。

项目是否有出现代码混乱，没有注释，没有详细文档的问题？明年的同学继续开发这个项目，会不会出现以上抱怨？如果一个新学生在一台新机器上想编译并运行你的项目，请问能顺利完成么？有什么样的文档能指导新学生？

项目文档清晰，鲁棒性强，易于上手继续开发。代码都带有了注释或通过函数名可以明确的了解函数功能。
语雀记录了完善的项目全流程文档，适合明年的同学接手快速了解项目结构。
使用了CI/CD等技术，不需要手动配置环境依赖，不会存在无法编译或者安装环境时各种报错的情况

项目是否有单元测试，测试用例数目，代码覆盖率等。

详见T15文档

后端使用junit对controller层http请求和websocket请求进行单元测试。
- http请求使用MockMvc模拟请求并采用数据库回滚方式对好友请求相关，游戏相关，广播消息和私聊消息相关，oj评测相关，房间相关以及登录注册相关功能进行多次测试。
- websocket请求本地建立客户端类，模拟多个客户端实现多线程模拟请求，测试单人模式匹配请求，局内聊天请求，番茄道具功能，大逃杀，房间内开启游戏以及提交答案等多人相关功能以及个人登录，光标移动等个人相关功能。
  测试结果总结如下：

部分行覆盖率情况如下：

websocket测试情况如下：

项目是否采用了CI/CD等软件工程工具，并说明理由。

采用了CI/CD，以自动化的方式提高服务器部署效率。
后端采用Docker对项目进行部署。

学到的经验和教训：整个团队在Beta阶段学到了什么，对软件工程有什么样的经验教训？

在Beta阶段，整个团队通过项目的持续推进和迭代优化，积累了宝贵的经验和教训。继承了Alpha阶段的合作模式，后端每个人负责一项技术的专攻，前端每个人负责一个模块的前端，然后两两合作。这种模式在Beta阶段继续执行并取得了显著成效，确保了项目的高效推进和各模块的稳定发展。针对Alpha阶段发布时出现的资源不足问题，团队对多线程高并发进行了重点优化和改进。在Beta阶段分配专门的测试人员进行了更为全面的压力测试，确保了系统在高并发情况下的稳定性。同时，引入了更多题目和大逃杀模式，增加了游戏的多样性和可玩性。特别是新道具的引入，不仅丰富了游戏内容，还为玩家提供了更多的策略选择。在Beta阶段，团队高度重视用户反馈，及时根据玩家的建议进行调整和优化，确保游戏体验的持续提升。

经验教训：尽管在本地进行了十多个账号的测试，但未能完全模拟真实环境下的资源需求，导致首次发布时因资源不足出现bug。Beta阶段教训深刻，即在测试中需要尽可能模拟真实场景，特别是高并发和资源消耗的测试。软件开发是一个持续改进的过程，Alpha和Beta阶段的迭代优化证明了不断修正和完善的重要性。每次迭代都应基于前一阶段的经验教训，进行有针对性的改进。

...全文