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

项目与团队亮点

成员与分工

合作分工表

姓名	任务
刘俊辰	PM、用户课程API及后端开发
温佳昊	评测API及后端开发
龚悦	前端开发（课程公告、评测提交、课程资源、个人中心）和美工
何天然	前端开发（架构、鉴权机制、api封装、CI/CD、Dockerfile、课程管理、作业列表、MR terminator）、前后端对接、评测文档
俞逸洋	前端开发（登录、作业题面、作业小测、用户管理、评测列表）和美工
王鹏宇	作业课程资源API及后端开发
申浩佳	服务部署、系统架构设计、运维

项目管理

代码管理

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

文档管理

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

API管理

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

软件工程质量

代码风格约定

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

团队新人加入

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

单元测试

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

CI/CD

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

经验教训

• 要重视鉴权和安全问题。由于团队中没有对网安相对较熟悉的同学，Alpha阶段出现的比较严重的问题均为安全问题
• 线下对接能够增加效率，在开发的关键阶段应该增加线下对接的次数，通常能够较快的发现问题并且当场解决
• 要多和用户交流，明确需求，避免在开发的过程当中重构
• Beta阶段主要完成的任务有重构评测机架构，完成讨论区、教程、成绩统计等功能

典型用户及场景

课程教师

数量约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 助教检索用户
  • H 助教编辑修正A同学的信息
  • H 助教批量导入新用户
  • H 助教调整表格的分页
  • H 助教单独添加了B同学的信息
• 课程管理
  • H 助教新增**“**2022编译技术”课程
  • H 助教修改课程名为”2023编译技术“
  • H 助教把21届的学生批量添加到课程
  • H 助教按列模糊搜索功能检查学生信息
• 提交记录
  • H 助教表通过提交记录表的模糊搜索功能找到 B 同学的历史提交
  • H 助教下载了他的历史提交文件

项目发布功能

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

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

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

• 用户管理
  • 添加删除用户
  • 修改用户信息、重置用户密码为默认值
• 课程管理
  • 添加修改删除课程
  • 添加删除课程开放用户
• 公告管理
  • 修改删除课程公告
• 资源管理
  • 添加更新删除资源
• 作业管理
  • 添加删除作业、修改作业题面
  • 创建更新删除小测
  • 延长作业时间
  • 评测管理
    • 添加更新删除评测
    • 添加更新删除数据点
    • 上传测试点文件

杀手级功能

评测

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

发布与活跃用户

项目推广

我们选择以6系20级和21级水群作为媒介，由PM着笔、共同修改得到宣发文案，于5.3中午在两个微信群中发布。在版本发布12小时内，有57位同学通过填写学号获得了账号。现平台共有8个管理员账号和62个学生账号，共70位用户。

活跃用户量

在日活用户量方面，达到alpha阶段预期数量。

截止5月4日14:32，已经有49人完成登录，API访问1852次，提交评测39次

截止5月4日20:28，Compilify-alpha用户交流群已有88人（其中7人为团队成员）

用户反馈与评价

用户功能反馈

来源	建议描述	是否采纳
微信聊天	移动端适配	将考虑在beta阶段实现
微信聊天	管理端表格表头筛选的存储	将考虑在beta阶段实现

用户bug反馈

在bug上的反馈，主要集中在平台安全相关问题以及用户权限问题上。

来源	bug描述	是否修复
微信聊天	minio 信息泄露	已修复
微信聊天	改密码时token不失效	已修复
微信聊天	关于部分按钮在没有相关数据情况下的可见性问题	已修复
微信聊天	用户可以通过修改url访问不包含该用户的课程	已修复
微信聊天	用运行在root权限下且没有密码的redis提权，可以进入容器修改源码	已修复
微信聊天	db中密码明文存储	已修复
alpha阶段用户微信群	修改密码后无法登陆	已修复

展示Demo

项目与团队总结

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

成员与分工

姓名	任务	个人博客
刘俊辰	PM、用户课程API及后端开发	https://blog.csdn.net/dawning_77?type=blog
温佳昊	评测API及后端开发
龚悦	前端开发（课程公告、作业评测提交、课程资源、个人中心）和美工	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
王鹏宇	作业课程资源API及后端开发	https://blog.csdn.net/wpydexiaoheiwu?type=bbs
申浩佳	后端开发（架构、鉴权机制、api封装、CI/CD、Dockerfile、MR terminator）服务部署、系统架构设计、运维	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 阶段目标。

实际进展（燃尽图）

贡献分配表

名字	团队贡献分	本职工作完成情况	其他贡献
刘俊辰	49	后端+单元测试代码3019行，完成部分博客	完成宣发文案
温佳昊	50	后端+评测机代码2100行，完成部分博客	评测机架构设计，docker配置
龚悦	50	前端代码1896行，完成部分博客
王鹏宇	49	后端+单元测试代码3281行，完成部分博客
俞逸洋	50	前端代码2173行，完成部分博客
何天然	51	前端代码3854行（包含架构代码），评测脚本325行，完成部分博客
申浩佳	51	后端+评测机代码1700行，完成部分博客	部署了minio、redis等环境，运维后端服务

典型用户场景

典型场景 — 普通作业

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

课程管理

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

提交记录

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

项目实现典型场景情况

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

综合考虑时间、功能重要程度、实现难度，我们认为这些功能实现难度大，且没有这些功能，平台仍能正常进行最核心的功能。因此未在 Alpha 阶段实现。

但这些功能仍然重要，以上四个功能计划将在 Beta 阶段实现。

杀手级功能

杀手级功能

评测系统

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

和竞品的比较

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

自我评价

基本上达到预期目标，但评测流程目前还不够完整，一些细节还待完善。