Compilify Beta阶段项目展示

本文为Compilify Beta阶段项目展示文档。

项目与团队亮点

成员与分工

合作分工表

姓名	任务
刘俊辰	PM、用户课程讨论区API及后端开发
温佳昊	评测API及后端开发
龚悦	前端开发（课程公告、评测提交、课程资源、个人中心、讨论区详情、通知管理、通知用户界面）和美工
何天然	前端开发（架构、鉴权机制、api封装、CI/CD、Dockerfile、课程管理、作业列表、MR terminator）、前后端对接、评测文档
俞逸洋	前端开发（竞速、讨论列表、成绩分析页面）和美工
王鹏宇	作业课程资源通知指导书GPT API及后端开发
申浩佳	服务部署、系统架构设计、运维

项目管理

代码管理

代码使用极狐进行管理，前后端和测评机分别创建仓库管理。

文档管理

文档使用Notion进行管理，由PM分配每次博客文档作业的各个部分，团队共同完成文档编写。

API管理

API使用了Apifox进行管理，前端后端确定需求后由后端人员把编写的API放到Apifox上供前端使用。API中规定了每个API的url、请求参数、参数体、正常响应、异常响应、返回结构体等行为。

软件工程质量

代码风格约定

大体使用了软工课程组之前给出的参考规范，后端使用golang常用的代码规范，前端使用eslint+prettier自动化检查代码风格

团队新人加入

• 如果团队有新成员加入，则可以通过Apifox查看文档、notion查看开发说明、文档等了解项目内容
• 项目的文档清晰，代码风格良好，易于新人继续上手开发。另外由于采用了docker容器化技术以及CI/CD，项目的打包部署不用手动配置环境

单元测试

我们对主要功能进行了单元测试覆盖率如下。部分覆盖率无法进一步提升是由于对数据库异常进行一定的检测， 这种异常难以在单元测试中完成触发。

CI/CD

项目的前后端、评测机均采用CI/CD自动部署，极大的减少了部署所需要的时间，并且能够通过CI/CD的执行发现项目的问题

经验教训

• 要重视鉴权和安全问题。由于团队中没有对网安相对较熟悉的同学，Alpha阶段出现的比较严重的问题均为安全问题
• 线下对接能够增加效率，在开发的关键阶段应该增加线下对接的次数，通常能够较快的发现问题并且当场解决
• 要多和用户交流，明确需求，避免在开发的过程当中重构

典型用户及场景

课程教师

数量约5-10位

用户	S 老师
年龄	～40岁
职业	编译技术 课程教师
需求	分析每次作业同学们的完成情况、收取实验报告、发布课程通知
期望	数据尽量直观，操作便捷

课程助教

数量约10-20位

用户	H 助教
年龄	～21岁
职业	学生，编译技术助教
需求	批量导入学生信息、发布或配置作业要求和教程、查看同学们的作业提交情况，给某些特殊情况的同学配置延时、给实验报告打分、解答讨论区帖子的问题，重要或优质帖子加精
期望	便于管理，操作便捷

课程学生

数量约400-450位，有计算机学院、软件学院、高等理工学院的学生

用户	A 同学	B 同学
年龄	～20 岁	~ 20 岁
职业	学生，选修编译技术课程	学生，选修编译技术课程
需求	方便查看各次作业要求细节、想挑战难度大的 MIPS 类别作业、将学习心得发布到讨论区、查看自己历次提交到性能数据、查看自己在整体性能排行榜中的位置，进一步优化	做作业时遇到问题，查看讨论区的解答帖子、讨论区还没有类似问题，进行发帖提问、想先尝试较为简单的 PCODE 类别作业
期望	作业提交评测时能快速反馈、能清晰看到自己已经获得的分数、可以清晰看到性能测试中历次提交的性能特点、希望提交作业时能提交到正确的位置，不希望错误提交到其他类别影响成绩计算	在讨论区方便分类查找已有帖子、提问能够尽快被解决、教程尽量清晰易懂、有辅助评测辅助 debug

典型场景

典型场景—课程公告

• S 老师在课程平台上发布了新的课程公告
• A 同学从首页公告栏处得知了新作业和DDL

典型场景—查看作业

• B 同学打开作业要求页面阅读
• H 助教修改作业要求

典型场景—小测

• H 助教为作业设置了小测题目
• B 同学做完小测，页面显示小测结果和正确答案

典型场景—提交评测

• B 同学尝试提交
• 平台提示他选择作业类型
• 评测机很快给出评判结果
• 平台显示本次作业的有效成绩和折算成绩
• B 同学下载标准输出和学生输出对比

典型场景—课程资料

• H 助教上传了往年的优秀报告
• A 同学进行下载

典型场景—个人中心

• B 同学切换课程
• B 同学给自己挑选了新头像
• B 同学修改默认密码为自己的常用密码
• B 同学退出登录

典型场景—即时通知

• H 助教撰写、编辑、发布通知给指定用户或全体
• B 同学收到来自课程组通知提醒
• B 同学收到讨论区订阅帖子动态提醒

典型场景—讨论区

• H 助教添加、删除 tag
• B 同学通过 tag 和关键词筛选和搜索帖子
• B 同学点赞、订阅帖子。
• B 同学点赞回复。
• H 助教回帖并为回复添加助教认证
• A 同学发帖分享经验
• H 助教设置帖子为精品

典型场景—竞速排序

• A 同学查看动态排名
• A 同学比对自己的历史提交变化

典型场景—指导书查看

• B 同学阅读指导书
• B 同学向GPT询问不懂的地方

典型场景—管理

• 用户管理
  • H 助教检索用户
  • H 助教编辑修正A同学的信息
  • H 助教批量导入新用户
  • H 助教调整表格的分页
  • H 助教单独添加了B同学的信息
• 课程管理
  • H 助教新增“2022编译技术”课程
  • H 助教修改课程名为“2023编译技术”
  • H 助教把21届的学生批量添加到课程
  • H 助教按列模糊搜索功能检查学生信息
• 班级管理
  • H助教新增“2023 S老师班”
  • H助教修改班级名为“2023-S老师班”
  • H助教将选课学生添加到班级
• 提交记录
  • H 助教表通过提交记录表的模糊搜索功能找到 B 同学的历史提交
  • H 助教下载了他的历史提交文件
• 成绩分析
  • S老师查看自己班级同学们历次作业的分数
  • S老师下载成绩分布直方图、导出成绩信息表格

项目发布功能

现行发布版本对学生用户提供了一系列基本功能：

• 个人相关
  • 登录登出（注册方式见下方安装使用方法）
  • 修改邮箱密码（其他信息不提供自由编辑，需联系助教/管理员修改）
• 公告相关
  • 查看课程公告
• 资料相关
  • 查看下载课程资料
• 作业相关
  • 查看作业介绍、测验、评测
  • 提交小测、查看小测答案
  • 提交评测、获取评测结果、下载提交、查看详情

在学生用户的基础上，对管理员用户进一步提供了用于管理的基本功能：

• 用户管理
  • 添加删除用户
  • 修改用户信息、重置用户密码为默认值
• 课程管理
  • 添加修改删除课程
  • 添加删除课程开放用户
• 公告管理
  • 修改删除课程公告
• 资源管理
  • 添加更新删除资源
• 作业管理
  • 添加删除作业、修改作业题面
  • 创建更新删除小测
  • 延长作业时间
  • 评测管理
    • 添加更新删除评测
    • 添加更新删除数据点
    • 上传测试点文件
• 讨论区
  • 创建、修改、删除讨论帖
  • 根据 tag 关键词查找、筛选讨论帖
  • 订阅、点赞讨论帖或回复
  • 加精、助教认证讨论帖
• 即时通知
  • 添加、删除、编辑、发布通知
  • 未读通知标记提醒
  • 确认阅读通知，筛选未读通知
• 成绩统计分析
  • 根据班级和作业查看学生成绩分布

杀手级功能

评测

	Compilify	Judge
评测界面	美丽，利用quasar组件库实现页面，与其他6系课程平台风格更贴近	页面布局不合理，信息密度过大
反馈信息	较全面，包含评测总结果、每个评测点的结果、标准输出、标准错误、答案等	部分反馈信息不明确，无下载功能等
响应时间	快速加载，不会卡顿	响应慢，卡顿
评测速度	快，一次编译，再利用进程池并发运行用户程序	单次评测时间长
评测环境	安全，使用docker，隔离运行时目录和网络	不确定是否断网

发布与活跃用户

项目推广

我们通过在微信群中发布软件信息，具体为在2020级和2021级6系水群中在6月9日晚发布消息，通过建立微信群和问卷的形式获得反馈，用户通过填写问卷获得账号。截至6月10日晚，用户交流群已累计达到126人。现平台共有5个管理员账号和79个学生账号，共84名用户。

活跃用户量

在日活用户量方面，达到beta阶段预期数量。
通过docker的log文件统计，截止6月10日21:28，用户已经完成121次登录，API访问4440次，提交评测331次

根据后台数据显示，截止6月10日23:34，平台共有84个账户，其中管理员及测试账户6个，由用户注册的账户78个。

根据数据库记录，提交小测、阅读公告等功能均有用户尝试。

受发布时间影响，目前未收到用户提交的评测。

用户反馈与评价

用户功能反馈

来源	建议描述	是否采纳
调查问卷	教程AI次数有点少	视成本适当增加限制

用户bug反馈

在beta阶段，截至6月10日22:56，问卷和用户群均未收到bug反馈。

用户评价

根据我们收集的问卷数据，用户在问卷中对整个平台、页面风格、系统的易用性、评测流程、公告作业资源等方面对我们的网站进行打分，可以看出用户对我们的平台评价较高：

	平均分
对于 Compilify 平台整体的评价	4.93
对于整体页面风格的满意程度	4.79
对于系统易用性的满意程度	4.86
对于评测流程及反馈的满意程度	4.93
对于查看公告、作业要求、资源下载的满意程度	4.79
对于小测功能的满意程度	4.86
对于讨论区的满意程度	4.93
对于教程指导书的满意程度	4.86
对于教程AI的满意程度	4.57
对于即时通知的满意程度	4.79

其中总体评价、评测功能、讨论区功能得分较高。
以下是部分用户对本平台的反馈：

展示Demo

Compilify Demo

Compilify 讨论区+通知

Compilify 指导书+GPT

项目与团队总结

本部分是对亮点部分补充说明

成员与分工

姓名	任务	个人博客
刘俊辰	PM、用户课程讨论区API及后端开发	https://blog.csdn.net/dawning_77?type=blog
温佳昊	评测API及后端开发	https://blog.csdn.net/weixin_44117693
龚悦	前端开发（课程公告、评测提交、课程资源、个人中心、讨论区详情、通知管理、通知用户界面）和美工	https://arthuring.github.io/
何天然	前端开发（架构、鉴权机制、api封装、CI/CD、Dockerfile、课程管理、作业列表、MR terminator）、前后端对接、评测文档	https://blog.csdn.net/weixin_51130923?type=blog
俞逸洋	前端开发（竞速、讨论列表、成绩分析页面）和美工	https://blog.csdn.net/emilyu2003?type=bbs
王鹏宇	作业课程资源通知指导书GPT API及后端开发	https://blog.csdn.net/wpydexiaoheiwu?type=bbs
申浩佳	服务部署、系统架构设计、运维	https://blog.csdn.net/shliba?type=blog

项目管理

项目开发使用jihulab进行管理，项目compilify-backend、compilify-frontend、compilify-judger分别是前后端和测评机的代码仓库。

项目进度使用"issues"完成每日任务，每晚由PM统计各成员完成的任务，在各子项目中创建 Issue 作为底层，实现项目进度的动态化管理。

项目使用Notion平台进行团队的文档管理、模块化结构等任务分配。在Notion中，任务直接分配到个人，每个人需要完成自己相应的内容。

项目合作基本原则：由大家协商共同决定是否将需求纳入实现范围

分工协作

根据编译平台开发的特性，我们使用前后端分离+测评机的模式，根据技术栈等综合因素的考量，将开发人员分工进行，实现项目效益最大化。

与此同时，项目的开发过程中涉及到需要无法均分的任务，对于这些特异化分工，我们选择交给指定的成员进行处理。

例如我们有灵活的开发补位者，具有全栈的就开发能力，能沟通解决前后端开发和对接遇到的难题，解决不协调的问题。

例如我们有开发工具的维护者，其了解DevOps 的最佳实践和CI/CD等自动化工具，主持架构设计，完成具体的部署问题。

沟通和对接

项目使用微信群+腾讯会议+线下进行项目进度的对接，其中遇到的问题通过Notion保留。沟通对接的方面主要有如下方面

1. 前后端开发的对接
2. 开发和部署的对接
3. 需求方和项目的对接
4. 迭代开发的对接

平衡 时间/质量/资源

我们尽量做到将任务分配到个人，这样做能将工作具体落实，尽量做到有条不紊。与此同时，PM分配任务时会评估任务难度在可控范围内，这样也能保证每个同学能够很好的完成任务。由于开发时间有限，我们以需求为导向进行取舍，将更多的精力用于保证 Alpha 阶段目标。

实际进展（燃尽图）

1. alpha阶段
   
2. beta阶段
   

贡献分配表

1. alpha阶段

名字	团队贡献分	本职工作完成情况	其他贡献
刘俊辰	49	后端+单元测试添加代码5244行，删除代码1107行，完成部分博客	进行会议记录、完成宣发文案、宣发
温佳昊	50	后端+评测机添加代码4207行，删除代码1939行，完成部分博客	评测机架构设计，docker配置
龚悦	50	前端添加代码3559行，删除代码1641行，完成部分博客
王鹏宇	49	后端+单元测试添加代码7304行，删除代码1358行，完成部分博客
俞逸洋	50	前端添加代码7898行，删除代码5697行，完成部分博客
何天然	51	前端添加代码5503行（包含架构代码），删除代码1619行，完成部分博客	配置评测脚本
申浩佳	51	后端+评测机添加代码3758行，删除代码478行，完成部分博客	部署了minio、redis等环境，运维后端服务

2. beta阶段

名字	团队贡献分	本职工作完成情况	其他贡献
刘俊辰	51	后端+单元测试添加代码3264行，删除代码505行，完成部分博客	进行会议记录、完成宣发文案、宣发
温佳昊	50	后端+评测机添加代码677行，删除代码635行，完成部分博客
龚悦	50	前端添加代码1860行，删除代码718行，完成部分博客
王鹏宇	51	后端+单元测试添加代码2287行，删除代码215行，完成部分博客
俞逸洋	50	前端添加代码3129行，删除代码1972行，完成部分博客
何天然	49	前端添加代码1718行，删除代码1502行，完成部分博客
申浩佳	49	后端+评测机添加代码1649行，删除代码378行，完成部分博客	运维后端服务

典型用户场景

典型场景 — 普通作业

新一周的编译课程开始了，同时也到了新一次作业的开启时间。S 老师在课程平台上发布了新的课程公告，通知大家新一次作业的起止时间。B 同学很快从首页公告栏处得知了新作业和DDL，他打算立即开工。

B 同学打开作业要求页面仔细阅读，但还是感到一些要求在细节上有些模糊。于是 B 同学打开讨论区，将自己的困惑写成提问帖发布，并附上了 tag 便于他人查找。帖子很快收到了同学们的回复，热度不断增加。H 助教也因此关注到了这个问题，在帖子中以助教身份做出明确回复，并给之前同学们的正确回复添加助教认证。同时，H 助教修改了原先不清晰的作业要求，并在通知栏提醒同学们作业要求的变动。

解决问题后，B 同学继续完成作业。B 同学在课程平台查看实验指导书，发现有一个概念不理解，他注意到指导书旁的“ 问问Chat GPT ”窗口，他决定先尝试问问看。Chat GPT 很快给出了概念的解释，通过不断对话追问的方式，B 同学对这个概念有了更好的理解。

困惑解答后，B 同学顺利的完成了作业。在提交作业时，B 同学先使用公开的辅助评测尝试提交。评测机很快给出了评判结果，果然没有一次通过。评测机提供了错误信息的前五行，B 同学为了查看详细错误信息，下载了标准输出和学生输出作为对比，并使用平台给出的编译命令复现错误。很快，B 同学找出了错误，改正后，他决定提交正式评测。由于初次接触编译实验，B 同学打算先完成较为简单的 PCODE 实验。在提交之前，平台提示他选择作业类型。确认作业类型无误后，B 同学提交并通过了评测。看到成绩一栏中出现了本次作业的有效成绩和折算成绩后，B 同学满意的关掉平台，睡大觉去了。

作业发布后，S 老师查看到了学生提交作业情况的实时统计，分析同学们的完成情况后，决定在下节课讲讲同学们作业中的难点，并叮嘱同学们按时完成作业。

典型场景 — 竞速作业

激动人心的 MIPS 赛道竞速作业终于开启了，A 同学早就蓄势待发，第一时间提交了作业。果不其然，A 同学在排行榜上名列前茅。看着随排行榜实时更新的竞速成绩，A 同学十分满意，去学别的课了。

几天之后，随着其他同学的提交不断增多，A 同学发现自己在排行榜上的位置越来越低。A 同学决定给自己的编译器再增添一些优化。他在总排行榜中仔细比对各个测试点的性能与前面同学的差距，发现自己还有很大提升空间后，A 同学开始了他的优化之路。

A 同学每完成一个优化，就在平台上进行一次提交。通过查看历史提交性能分析，A 同学看到了每个优化带来的性能提升。这让 A 同学十分有成就感，并且对于哪些优化和优化组合更加重要有了深刻的理解。终于，几次优化迭代后，A 同学又回到了排行榜顶端。

典型场景—讨论区

A 同学将自己的优化思路和心得总结成了博客，并发布到了对应的讨论区作为经验分享贴。H 助教看到这篇帖子，认为 A 同学写的非常棒，给这篇帖子设置为了精品帖，吸引更多的同学来阅读学习。

竞速作业接近尾声，A 同学将自己的详细实验过程写成实验报告，提交到了文档作业窗口中。H 助教和 S 老师负责评判实验报告。在阅读完 A 同学的实验报告后，他们认为 A 同学很好的完成了编译实验，于是给 A 同学打出高分。A 同学看到实验报告分数后，满意的关掉平台，去学别的课了。

典型场景—课程公告

新一周的编译课程开始了，同时也到了新一次作业的开启时间。S 老师在课程平台上发布了新的课程公告，通知大家新一次作业的起止时间。B 同学很快从首页公告栏处得知了新作业和DDL，他打算立即开工。

典型场景—查看作业

B 同学打开作业要求页面仔细阅读，但还是感到一些要求在细节上有些模糊。H 助教也因此关注到了这个问题，H 助教修改了原先不清晰的作业要求。B 同学继续开心的做作业。

典型场景—小测

为了加深同学们的对题面的理解，确保同学们注意到了作业要求细节，H 助教为作业设置了小测题目。

B 同学看完作业要求后，马上把小测都做完了，并进行了提交。页面上立即出现了小测结果，错误的题目会显示正确答案。B 同学对照答案后，更加深刻的理解了作业要求，他非常高兴的继续做作业。

典型场景—提交评测

B 同学顺利的完成了作业。在提交作业时，B 同学先使用公开的辅助评测尝试提交。评测机很快给出了评判结果，果然没有一次通过。评测机提供了错误信息的前五行，B 同学为了查看详细错误信息，下载了标准输出和学生输出作为对比，并使用平台给出的编译命令复现错误。很快，B 同学找出了错误，改正后，他决定提交正式评测。由于初次接触编译实验，B 同学打算先完成较为简单的 PCODE 实验。在提交之前，平台提示他选择作业类型。确认作业类型无误后，B 同学提交并通过了评测。看到成绩一栏中出现了本次作业的有效成绩和折算成绩后，B 同学满意的关掉平台，睡大觉去了。

典型场景—课程资料

写总结报告的时间到了，为了给大家一些方向，H 助教上传了往年的优秀报告供大家参考。A 同学看到后，立即进行下载。参考了往届优秀学长学姐的报告，A 同学的报告内容更加丰富起来，方向更加明确，最终提交了一份优秀的报告！

典型场景—个人中心

新的学期开始了！B 同学由于对上一学年的编译课程成绩不太满意，他今年决定重修编译课程！B 同学登陆了熟悉的账号，确认自己的信息无误后，将自己的课程切换到了新一年的编译课程。新年新气象，B 同学给自己挑选了新头像，并修改默认密码为自己的常用密码。做完这些，B 同学满意的退出登录，期待新一年能有更好的编译成绩！

典型场景—即时通知

语法分析作业快要截止了，助教 H 发现部分同学进展较慢，希望单独通知提醒他们加快进度。助教 H 撰写好通知内容，添加好通知人。在发布前，助教 H 检查并修改通知中的错误。确认无误后，助教 H 发布了通知。

此时，B 同学正努力阅读课程平台上的指导书，看到页面右上角的消息图标出现了两条新消息提示。B 同学点开一看，其中一条来自课程组的 H 助教，提醒他尽快完成作业，另一条来自讨论区订阅提醒，B 同学关注的帖子更新了！这条更新内容给 B 同学带来了很大启发，继续完成作业去啦。

典型场景—讨论区

在完成作业的过程中，同学 B 对作业中的要求有些不确定，他在讨论区进行了发帖提问，并添加了对应作业的 tag。正巧今日助教 H 值班，他通过筛选 tag 来查看同学们关于当前作业的帖子，注意到了 B 同学的问题。他在 B 同学的帖子后进行了答疑回复，并添加了助教认证证明信息的真实性。带有助教认证的回复解决了 B 同学心中的疑惑，B 同学给助教 H 的回复点赞，继续开心的写作业去啦。

A 同学是一个乐于分享的同学，他将完成作业的经验和自己的优秀编译器架构总结成了帖子发到了讨论区的对应 tag 中。B 同学在编译器架构设计上迟迟找不到方向，通过搜索“架构设计”看到了 A 同学的分享。B 同学认为他的的帖子内容详实，看完后大彻大悟，给 A 同学的帖子点了一个大大的赞，并回复和订阅了 A 的帖子，表达对这篇帖子的赞美。优秀的内容吸引了更多的同学在帖子后回复讨论，同时也让助教 H 眼前一亮。助教 H 将这篇帖子设置为精品帖，便于同学们筛选有效信息。

典型场景—竞速排序

激动人心的 MIPS 赛道竞速作业终于开启了，A 同学早就蓄势待发，第一时间提交了作业。果不其然，A 同学在排行榜上名列前茅。看着随排行榜实时更新的竞速成绩，A 同学十分满意，去学别的课了。

一段时间后，A 同学看到自己的排名位次逐渐下降，他决定进行进一步优化设计。通过查看历次提交的提交备注和性能详情，A 同学观察到了提升方向。一番修改后，A 同学添加了新的强力优化，并在提交时备注优化方便之后查看。A 同学再次查看历次提交性能记录，看到了各个优化的具体效果和不同优化组合带来的性能变化。A 同学十分满意，去学别的课了。

典型场景—指导书查看

实验作业开始了！A同学点开指导书界面，开始在线阅读实验教程。随着实验进度，指导书章节不断发布，便捷的目录、详尽的文字让A同学受益匪浅。但在学习语义分析一章时，A同学对指导书内容产生了疑问，于是点开右下角的gpt对话框，找到“语义分析”的聊天，翻阅了聊天记录后，向语义分析AI提出了自己的问题并获得了满意的回答。

典型场景—管理

用户管理

H助教想要查看所有20级的用户，于是进入用户管理界面，在年级一栏的搜索框中输入2020进行检索。H助教突然发现，A同学的专业不对，于是点击编辑，修正了A同学的信息。接着，H助教导通过使用右下角按钮的批量导入功能，在表格中添加了2021级的新用户们。表格长了许多，H助教通过调整表格的分页，让界面看起来更清晰了一些，同时把右下角的管理按钮拖到了不碍事的地方。B同学向H助教反映自己无法登陆，于是H助教在表格中进行检索，发现B同学确实不在用户列表中，于是单独添加了B同学的信息。

课程管理

为做好新一学期课程的准备，H助教打开课程管理界面，新增了一个名称为“2023编译技术”的课程。但是——H助教想起了去年上课的场景，手抖打成了“2022”，于是急忙点击修改课程，输入了课程的正确名字。通过用户管理的批量导入功能，H助教把21届的学生们都添加到了课程中。经过人数的核对，并利用便捷的按列模糊搜索功能，H助教发现有重修的B同学没能进入这个列表，于是手动添加了该学生到课程中。

班级管理

学生选课结束后，H助教导入各个班级的信息，添加班级的名称、教师姓名与学生信息，以便后续更便捷地进行成绩信息统计。后续班级产生了人员变动，H助教通过增删学生以及修改班级信息快速解决了问题。

提交记录

B 同学正在风风火火的完成他的作业。他已经通过了所有评测，但 B 同学显然并不打算止步于此，他继续思考如何优化架构。一番重构之后，他的最新提交竟然没有通过测试。B 同学平时没有版本管理的习惯，在本地没有保存以前已通过的代码，平台上的提交记录又被覆盖了。眼看作业即将截止，B 同学心急如焚，只得联系 H 助教帮忙。H 助教表示这不是大事，他通过提交记录表的模糊搜索功能找到 B 同学的历史提交，并下载了他的历史提交文件，帮助 B 找回了之前通过的版本。B 同学高兴极了，他下定决心之后一定好好做版本管理。

成绩分析

学期即将结束，S老师想要看看自己班里的同学们作业都完成的怎么样了，于是点开成绩分析，按照班级对学生的成绩进行筛选检索。看完后S老师决定把信息存下来，于是点击“导出”按钮，获得了该次查询的表格；点击柱状图上方的下载按钮，获得了该次查询的成绩分布图。

项目实现典型场景情况

Alpha 阶段满足了除指导书、讨论区、成绩数据统计、竞速排序、即时通知之外的所有应用场景。

在 Beta 阶段，我们实现了以上五个重要功能，使得课程平台的功能更加丰富完善。可以覆盖所有编译课程需求。

此外，我们制定了前端颜色、弹窗等规格，使得整体界面更加美观统一。

杀手级功能

杀手级功能

评测系统

• 美观的评测界面：利用quasar组件库实现页面，与其他6系课程平台风格更贴近
• 详细的反馈信息：包含评测总结果、每个评测点的结果、标准输出、标准错误、答案等
• 更短的响应时间：前端加载速度更快，不会造成卡顿
• 更快的评测速度：一次编译，再利用进程池并发运行用户程序
• 安全的评测环境：docker隔离运行时的目录和网络

和竞品的比较

竞品希冀平台也基本实现了上述功能，但是存在不少问题，例如单次评测过慢、页面响应时间太长、卡顿等等。我们团队重新设计了UI，完善了反馈机制，让学生更好地获取评测信息。同时我们重新设计了数据模型，做了查询优化，从而加快前端响应速度，不会造成页面卡顿。而对于评测机，我们改良了评测流程，使得每个测试点的评测高度并发，尽可能地缩短了单次评测时间。

自我评价

我们的课程项目应用了新技术、融合了软件工程思想，找好了切入点，将编译课程的传统需求和同学的新增需求巧妙结合，较好地解决了原编译课程平台ui不美观，评测较慢的痛点，增加了在线教程，并且融入AI教学，使同学们学习更方便，综合来说，相较原有平台有较大提升，能够帮助课程组更好的建设课程体系。