团队作业6——Alpha 阶段项目复审报告
课程：《软件工程》
复审人：袁梓轩、黄龙宇、赖柏源
复审时间：2025-12
一、复审说明
本文为《软件工程》课程 团队作业6——复审与事后分析 中的 Alpha 阶段项目复审报告。
作为复审人，我对本班其余团队已发布的 Alpha 项目进行了博客阅读、代码仓库检查以及功能层面的分析与对比，并从 程序质量 与 软件工程质量 两个维度进行综合评估，最终给出无并列排名及对应点评。
本次复审不包含本团队项目。
二、复审方法与评价标准
本次复审主要从以下几个方面进行：
- 程序质量：是否解决原计划要解决的问题，核心功能是否可运行，是否存在影响主流程的 Bug；
- 软件工程质量：代码是否公开、是否能在新环境构建，代码结构与可维护性如何；
- 项目管理情况：是否有需求拆解、阶段目标，燃尽图是否反映真实状态；
- 需求取舍与风险应对：是否识别用户痛点，对主要与次要需求有合理取舍；
- 复审人反思：如果由我来领导该项目，会在哪些方面做出不同决策。
评价依据遵循课程所强调的公式：
软件质量 = 程序质量 + 软件工程质量
三、Alpha 阶段项目综合排名（无并列）
| 排名 | 小组名称 | 项目名称 |
|---|---|---|
| 1 | 带派不队 | iBlog Community 多用户博客社区 |
| 2 | coding小分队 | 图书管理系统 |
| 3 | NoteForces 团队 | 简易在线笔记系统 |
| 4 | 蛋仔派队 | 体育场馆预约系统 |
| 5 | KFCoder | 日常健康打卡系统 |
| 6 | 在线考试系统 | 在线考试系统 |
| 7 | 哥们废了 | 哥们记了（账单分析工具） |
| 8 | 东拼西凑 | 云档集成管理平台 |
| 9 | 广工校园论坛 | 校园论坛系统 |
| 10 | 从容应队 | 大学生健康生活管理与预警系统 |
| 11 | TanhT | 高校开发者博客系统 |
| 12 | team 1 | eSIM Store |
| 13 | team 3 | 天空外卖系统 |
四、各项目复审点评
第 1 名：带派不队 —— iBlog Community 多用户博客社区
项目链接：https://github.com/maple525866/WorkingBlog
优点：
功能完整且落地扎实，全面实现了博客发布、编辑、归档、用户个人主页展示及评论互动等核心功能，形成了 “内容管理 + 社区交流” 的完整闭环；界面采用 Element UI 构建，设计美观且布局清晰，交互流程符合用户直觉，加载状态提示、路由跳转等细节处理流畅；源代码按模块化拆分，目录结构规范，变量命名与注释严谨，同时配套详细的开发文档与部署指南，极大提升了项目的可维护性与易用性。
缺点与 Bug 分析（≥140 字）：
博客归档按时间筛选时，月份选择器偶尔无响应；评论区连续回复超过 5 条会出现样式错位。项目目标基本全部实现，风险应对较完善（做了数据备份方案）；精准覆盖了 “个人内容展示 + 社区互动” 的用户痛点；需求取舍合理（优先保证核心功能，暂存 “博客模板切换” 等次要需求）；若带队会增加性能优化（大流量下的页面加载速度），补充移动端适配细节。
如果由我来负责该项目：
在保持当前功能稳定性的前提下，我会在 Alpha 阶段后期尽早引入基础的性能监控与压力测试机制，例如通过压测工具模拟多用户同时访问博客列表、评论区和用户主页的场景，以量化系统在高并发条件下的响应时间和资源占用情况。同时，我会将现有的交互 Bug（如评论区样式错位）纳入专门的回归测试清单，确保后续功能迭代不会引入新的回归问题。在工程层面，我还会进一步细化移动端适配方案，使博客系统在不同终端上的体验更加一致，为后续可能的用户规模扩展提前做好准备。
第 2 名：coding小分队 —— 图书管理系统
项目链接：https://github.com/ywks1/library-system
优点：
| 该小组选择了经典但具有现实需求的“校园图书管理系统”作为项目主题，问题背景真实，目标用户明确，具备较强的落地价值。从软件工程角度看，整体技术架构设计较为完整，前后端分离（Vue + SpringBoot）、数据库与缓存（MySQL + Redis）、鉴权机制（JWT）以及容器化部署预留，体现了对工程化实践的重视。团队分工细致且覆盖面广，项目经理、前后端、测试运维职责清晰，有助于降低协作成本。项目计划拆分合理，开发节奏从需求调研、原型设计到核心功能实现循序渐进，符合软件工程的基本流程。功能规划覆盖检索、借阅、预约、推荐等典型场景，与校园图书馆的真实业务高度契合。
缺点与 Bug 分析（≥140 字）：
从 Alpha 阶段来看，该项目存在“目标偏大、实现风险偏高”的问题。预期日活 2000+、覆盖 90% 在校师生的目标较为理想化，而目前尚未看到明确的性能测试数据与并发场景验证，尤其是借阅高峰期的并发冲突处理策略仍停留在设计层面。功能规划较多（推荐系统、电子资源、预约排队等），但在 Alpha 阶段更应优先保证核心借阅流程的稳定性与正确性。软件工程方面，仓库中对构建流程、部署步骤和测试自动化的说明仍不够充分，代码在“新机器是否能一键跑通”上存在不确定性。如果由我来主导该项目，会在当前阶段主动收缩功能范围，将智能推荐和电子资源延后，集中精力打磨借阅、归还、权限与数据一致性，并通过更明确的测试指标来量化系统质量。
如果由我来负责该项目：
我会在 Alpha 阶段对项目目标进行主动收缩，将智能推荐、电子资源管理等高复杂度功能明确标记为 Beta 或后续版本内容，集中精力打磨“借阅—归还—权限校验—数据一致性”这一核心业务链路。同时，我会补充完整的新环境构建文档和一键启动脚本，以验证代码在陌生环境下的可运行性。在测试方面，我会通过并发借阅场景测试来验证系统在高峰时段的稳定性，并用明确的数据指标来支撑系统质量评估，而不是仅停留在功能描述层面。
第 3 名：NoteForces 团队 —— 简易在线笔记系统
项目链接：https://github.com/iikachan/noteforces
优点：
核心功能落地完整，笔记增删改查、分类管理与 Markdown 编辑均已实现，产品目标明确，系统已具备实际可用性。界面设计简洁，响应式布局适配多端，技术架构务实。
缺点与 Bug 分析（≥140 字）：
当前系统存在多项影响体验的 Bug，例如长文本编辑时出现卡顿甚至闪退，分类标签删除后笔记状态异常，且缺乏自动保存机制，存在数据丢失风险。从工程角度看，风险应对不足，未针对用户数据安全做充分设计。此外，源代码管理存在一定混乱，多人协作时冲突处理不够规范。虽然整体功能可用，但稳定性仍需加强。
如果由我来负责该项目：
在 Alpha 阶段，我会优先将工作重心放在数据安全和用户内容保护上，而不是继续扩展新功能。具体来说，会尽早引入自动保存与草稿机制，降低用户因异常刷新或崩溃导致的数据丢失风险。同时，我会针对长文本编辑卡顿问题进行性能分析，定位前端渲染或状态管理瓶颈。在工程管理层面，我还会规范分支管理和协作流程，通过 Code Review 和冲突解决规范，提升多人协作时的代码质量与开发效率。
第 4 名：蛋仔派队 —— 体育场馆预约系统
优点：
该小组在 Alpha 阶段已经交付了一个功能完整且经过系统性验证的预约系统。从程序质量来看，系统完整实现了“注册—登录—查看场馆—预约—取消—通知—管理端审核—数据统计”的核心业务闭环，并针对学生、教职工、社团和管理员等多类用户设计了差异化使用场景。测试报告显示，项目共执行 85 条 API 测试脚本、200 次/分钟并发预约压力测试，并通过行锁与事务回滚机制有效避免了重复预约问题，说明其后端逻辑具备较好的稳定性和一致性。从软件工程角度看，该团队采用多种测试策略组合，并对 Bug 进行分类、统计和回归验证，出口条件明确，能够用定量数据证明 Alpha 版本的质量水平，体现了较成熟的软件工程意识。
缺点与 Bug 分析（≥140 字）：
尽管该项目在功能和测试层面表现较为突出，但在工程交付和发布方式上仍存在一定局限。首先，Alpha 版本采用单机本地部署（localhost），未提供公网访问方式或可复现的部署脚本，这使得复审者和潜在用户难以独立验证系统运行情况，降低了软件可复现性。其次，测试报告中虽然详细列出了 32 个 Bug 及其修复状态，但目前尚未看到这些 Bug 与代码仓库中的 Issue、提交记录形成一一对应关系，Bug 管理与源代码管理的关联性有待加强。在需求取舍方面，系统功能覆盖面较广，Alpha 阶段已实现大量管理和统计功能，但也导致部分非核心 Bug 被延期修复，后续版本中仍需警惕功能复杂度持续上升带来的维护风险。如果由我来领导该小组，我会在保持现有测试深度的基础上，优先补充标准化部署说明和最小公网 Demo，并将测试缺陷与代码提交强关联，以进一步提升工程透明度和可维护性。
如果由我来负责该项目：
在保持现有测试深度优势的基础上，我会进一步补充复杂预约冲突场景和极端并发条件下的专项测试，例如模拟热门场馆在短时间内被大量用户同时预约的情况，并通过测试数据验证事务锁和回滚机制的有效性。同时，我会优先补充标准化的部署说明和最小公网 Demo，使系统能够被第三方独立复现和验证，从而提升项目在工程交付和展示层面的完整度。
第 5 名：KFCoder —— 日常健康打卡系统
优点：
该小组在 Alpha 阶段已经交付了一个功能闭环完整、工程质量突出的健康打卡系统。从程序质量角度看，系统完整实现了用户注册与登录、运动/饮食/饮水/睡眠四类健康打卡、历史记录查询、数据统计展示以及提醒设置等核心功能，且主流程在真实后端环境中可稳定运行。从软件工程角度看，团队在 Alpha 阶段即建立了成熟的自动化测试体系，前端通过 Selenium 完成 22 条 UI 自动化用例，后端通过 pytest + requests 完成 18 条 API 自动化用例，并对核心业务规则（如每日唯一打卡、参数边界校验）进行了专门验证，测试覆盖率和通过率均达到 100%。此外，测试报告结构清晰，Bug 分类、修复率和出口条件均有量化指标，体现了较强的软件工程规范意识和质量保障能力。
缺点与 Bug 分析（≥140 字）：
尽管 team 5 在 Alpha 阶段整体质量较高，但项目仍存在一些可以改进的地方。首先，在兼容性与性能方面，当前测试矩阵主要集中在桌面端浏览器和低并发场景，对移动端设备、高并发访问以及弱网环境的覆盖仍较有限，而健康打卡类应用在真实使用中具有明显的移动端和高频访问特征。其次，虽然自动化测试体系非常完善，但代码质量目前主要通过测试结果进行间接评估，尚未结合静态代码分析、代码规范检查或系统性的 Code Review 记录。最后，在发布形态上，当前版本仍以源码方式部署为主，缺乏 Docker 镜像或一键部署方案，增加了项目在新环境中的使用和演示成本。如果由我来领导该小组，我会在保持现有自动化测试优势的基础上，引入持续集成（CI）流程和标准化部署方案，并补充性能与并发测试，以进一步提升系统的工程成熟度。
如果由我来负责该项目：
我会在 Alpha 阶段明确区分“数据记录”和“健康分析”两类需求的优先级，优先保证基础打卡数据的完整性、准确性和异常处理能力，例如对漏打卡、重复提交和异常参数进行更系统的校验。在工程实践方面，我会在现有自动化测试基础上引入持续集成（CI）流程，将测试、构建和质量检查自动化，并补充性能测试与移动端兼容性测试，以进一步提升系统在真实使用场景下的稳定性。
第 6 名：在线考试系统
优点：
核心考试流程落地完整，成功实现了题库管理、自动组卷、客观题自动评分等核心功能，满足线上考试的基础需求；针对考试场景进行了针对性优化，增加了考试计时、防切屏提示等功能，贴合线上考试的严肃性与规范性要求；配备的数据统计模块能够生成基础成绩报表，为教师评估考试结果提供了有效支持，整体功能围绕 “线上考试” 核心场景形成了可用的闭环。
缺点与 Bug 分析（≥140 字）：
自动组卷功能未体现题目去重逻辑易出现重复题目，考试过程缺乏断网缓存机制导致网络波动时答题数据丢失，主观题仅支持文字输入且无图片 / 附件上传功能；项目未完成 “错题本”“考试数据分析” 等计划模块，风险应对不足，同时未覆盖教师 “批量导入题库” 的高频需求；源代码中数据库连接配置采用明文填写密码的方式，存在明显安全隐患，整体在功能稳定性、需求覆盖度及数据安全上有较大提升空间。
如果由我来负责该项目：
在 Alpha 阶段，我会将数据安全与考试稳定性作为最高优先级，首先解决数据库凭据明文存储和考试中断数据丢失的问题，例如引入环境变量管理和本地缓存机制。同时，我会针对自动组卷逻辑补充去重与题目覆盖率验证测试，确保考试公平性。在需求管理上，我会明确将“错题本”和复杂分析功能延后，集中资源保证考试主流程在异常网络条件下仍能可靠运行。
第 7 名：哥们废了 —— 哥们记了（账单分析工具）
优点：
该项目目标明确，聚焦“学生消费账单分析”这一真实且高频的使用场景，相比通用记账软件选择了差异化切入点，强调“本地处理 + 消费洞察”，在隐私保护和使用负担上具有现实价值。从程序质量看，项目采用 Pandas 进行账单清洗与聚合，技术选型合理，适合批量数据处理；通过 Flask 提供 REST API，也体现了前后端解耦的工程意识。功能设计基本覆盖账单导入、自动分类、可视化和简单洞察，整体与最初目标保持一致。团队分工清晰，角色覆盖项目管理、架构、测试和文档，体现了一定的软件工程组织能力。
缺点与 Bug 分析（≥140 字）：
目前 Alpha 阶段仍存在一些明显不足。首先，自动分类高度依赖关键词规则，在账单描述不规范或新商户场景下容易误判，缺乏可量化的分类准确率评估。其次，用户系统与数据隔离描述较为概念化，尚未看到明确的权限模型与异常处理方案，存在数据混淆风险。从软件工程角度看，源代码的构建说明、依赖管理和在“新机器上是否可一键运行”方面信息不足，测试更多是功能验证而非系统化测试（如边界数据、异常账单）。燃尽图和风险应对更多是事后描述，和实际开发节奏的映射关系不够直观。如果由我来负责该项目，会在 Alpha 阶段优先压缩功能面，强化分类准确性评估、自动化测试和部署文档，而不是继续扩展可视化形式。
如果由我来负责该项目：
我会在 Alpha 阶段主动压缩功能范围，优先提升账单分类准确性和系统稳定性，而不是继续扩展可视化形式。具体来说，会通过采样账单数据对分类规则进行评估，并引入基础的准确率指标来量化分类效果。在工程层面，我会补齐构建与部署说明，并引入自动化测试覆盖异常账单和边界数据场景，以提升系统在真实使用环境下的可靠性。
第 8 名：东拼西凑 —— 云档集成管理平台
优点：
该小组选择的云档集成管理平台选题具有很强的现实性，文件上传、管理和分享是普遍存在的真实需求，不依赖特定场景，应用边界清晰。从技术角度看，项目涉及断点续传、分片上传、秒传等功能，这些都不是“表面功能”，对后端并发控制、状态管理和数据一致性都有一定要求，能够支撑软件工程课程的学习目标。团队分工较为合理，前后端与测试角色齐全，职责描述清晰，避免了所有人都挤在同一模块上的情况。项目计划覆盖需求分析、原型设计、架构设计、Alpha 冲刺和测试等阶段，整体流程完整，体现了一定的软件工程意识，而不是只关注代码实现。
缺点与 Bug 分析（≥140 字）：
目前该项目在选题和功能规划上存在一定“目标偏高”的风险。秒传、断点续传等功能实现难度较大，如果同时推进，容易影响核心功能的稳定性。从当前展示内容来看，对核心功能与扩展功能的优先级区分仍不够明确，后续如果时间受限，可能出现功能完成度不均的问题。在软件工程层面，虽然团队计划较为详细，但具体的质量衡量方式（如如何验证上传可靠性、异常中断场景的测试覆盖情况）仍偏宏观，需要在 Alpha 阶段通过测试报告进一步量化。此外，项目以本地或私有化部署为目标，但对部署复杂度和普通用户可用性的描述还不够具体，存在一定的使用门槛风险。
如果由我来负责该项目：
在 Alpha 阶段，我会对功能优先级进行明确分层，将断点续传作为核心目标，其余如秒传等功能暂缓推进，避免高复杂度功能叠加影响整体稳定性。同时，我会通过明确的测试用例来验证上传失败、网络中断等异常场景下的数据一致性。在工程交付方面，我还会补充简化部署方案，以降低系统使用和复现门槛。
第 9 名：广工校园论坛
优点：
围绕校园场景完成了核心功能闭环：通过实现发帖、回帖的互动流程搭建了基础交流框架，校园板块的定向分类贴合学生话题聚集需求，基础的用户注册登录功能则保障了身份管理的基本逻辑，从博客内容推测，开发过程中可能对核心流程的落地有较清晰的推进，初步满足了校园论坛的基础使用场景。
缺点与 Bug 分析（≥140 字）：
发帖时上传图片会出现格式不兼容（仅支持 JPG，PNG 上传后无法显示）；回帖楼层排序混乱（新回复会插入到楼层中间）；无内容审核机制，存在垃圾信息风险。项目目标未完成 “帖子置顶”“用户等级” 模块；风险应对缺失（未考虑内容安全问题）；源代码无注释，后期维护难度大；若带队会补充需求调研，增加功能原型测试，完善代码文档规范。
如果由我来负责该项目：
我会首先修复影响核心交互体验的 Bug，如图片上传兼容性和楼层排序问题，确保论坛的基本交流流程稳定可用。同时，我会引入基础的内容审核与权限控制机制，以降低垃圾信息和内容风险。在工程管理层面，我会补充代码注释与文档规范，并通过原型测试提前验证关键交互设计，减少后期返工。
第 10 名：从容应队 —— 大学生健康生活管理与预警系统
优点：
该小组的选题具有较强的现实针对性，聚焦大学生健康管理这一长期存在但容易被忽视的问题，切入点明确，社会意义较强。系统定位清晰，将生活行为记录、健康分析与预警、校医院资源对接进行整合，整体思路完整，不是单一功能的堆砌。从团队展示来看，分工合理，前后端、测试和项目管理角色齐全，且 GitHub 分支规划较为规范，体现了对协作流程和代码管理的重视。项目计划覆盖需求调研、原型设计、核心功能开发、测试与部署等阶段，流程较完整，符合软件工程课程对“过程”的要求。此外，在用户体验与人文关怀层面，项目强调“温和提醒”“陪伴式管理”，目标明确，容易形成统一的产品方向。
缺点与 Bug 分析（≥140 字）：
该项目在选题层面也存在一定挑战，主要体现在目标规模和实现复杂度较高。预期覆盖 1–3 万学生并对接校医院体检系统，在真实环境中涉及数据获取权限、隐私保护与系统对接难度，而目前更多停留在概念设计阶段。功能范围较广（生活记录、健康分析、风险预警、心理测评等），如果同时推进，可能对 Alpha 阶段的完成度和稳定性产生压力。在软件工程角度，虽然分支和计划设计较完善，但对核心算法（健康风险评估、预警规则）的量化标准与验证方式描述仍偏笼统，后续需要通过测试数据和明确指标来支撑“智能分析”的有效性。若时间受限，建议优先保证数据记录与基础分析的可靠性，再逐步扩展预警和联动功能。
如果由我来负责该项目：
在 Alpha 阶段，我会主动收缩功能目标，将复杂的健康预警与心理测评模块延后，优先保证数据采集、存储和基础展示的稳定性。同时，我会明确健康分析指标的量化标准，并通过小规模测试数据验证分析结果的合理性，以避免系统长期停留在概念层面。
第 11 名：TanhT —— 高校开发者博客系统
优点：
该小组选择的项目具有明确的目标用户和应用场景，围绕高校开发者的内容创作与管理需求，设计了完整的文章管理与审核流程。从程序质量角度看，Alpha 版本已经实现了文章及分类的 CRUD、用户登录、文章筛选等核心功能，并通过 Mock 接口保证了前端功能的完整演示，使“创作—审核—发布—展示”的主流程能够顺畅跑通。在软件工程方面，团队在 Alpha 阶段给出了清晰的测试报告，对 Bug 进行了分类统计，并明确了出口条件和发布标准，说明项目并非停留在功能堆砌，而是具备基本的工程评估意识。此外，团队在场景测试中清晰区分了编辑、管理员和访客三类角色，功能组合逻辑合理，符合实际内容管理系统的使用方式。
缺点与 Bug 分析（≥140 字）：
尽管 TanhT 博客园在 Alpha 阶段完成了核心功能演示，但当前版本在程序和工程层面仍存在较为明显的局限。首先，Alpha 版本完全基于 Mock 数据运行，未接入真实后端服务，数据无法持久化，页面刷新后所有操作都会丢失，这使得系统的稳定性、数据一致性以及多用户协作能力无法得到验证。其次，测试报告中虽然统计了 9 个 Bug 并修复了部分关键问题，但测试范围主要集中在前端功能表现，缺乏对真实接口、权限校验和异常业务场景的验证，程序质量更多体现为“演示可用”而非“系统可用”。在需求取舍方面，团队在 Alpha 阶段较好地聚焦了文章管理这一核心需求，但搜索功能仍处于待完善状态，说明部分关键体验功能尚未完全落地。如果由我来领导该小组，我会在下一阶段优先推动真实后端接入和数据持久化，并通过接口级测试来验证系统在真实环境下的可靠性，而不是长期依赖 Mock 数据。
如果由我来负责该项目：
我会优先推动真实后端服务的接入，解决当前依赖 Mock 数据的问题，使系统具备数据持久化和多用户协作能力。同时，我会通过接口级测试验证权限校验和异常场景，并补充部署说明，确保系统能够在新环境中稳定运行，而不是仅作为前端功能演示。
第 12 名：team 1 —— eSIM Store
优点：
该小组的项目定位清晰，针对全球旅行者使用 eSIM 的实际需求，设计了完整的“搜索—选择—购买—激活”业务流程，符合真实用户使用场景。从工程实现上看，项目采用 Next.js + TypeScript 技术栈，目录结构清晰，模块划分合理（app、components、utils 等），并配置了 ESLint、TypeScript 和构建相关文件，体现了较好的工程化意识。在 Alpha 阶段，小组提供了较为完整的测试报告，明确列出了测试类型、测试用例数量、缺陷分类及处理状态，能够用定量数据说明当前系统的质量水平，而不是仅停留在主观描述层面，这在同类项目中是比较少见且值得肯定的。
缺点与 Bug 分析（≥140 字）：
从目前公开的仓库情况来看，该项目在程序可运行性和工程落地程度上仍存在明显不足。首先，仓库中缺少清晰、完整的 README 文档，没有明确说明项目的运行环境、依赖配置以及启动步骤，导致代码在新的机器上能否成功构建无法验证，这在 Alpha 阶段属于较为关键的问题。其次，虽然项目目标是实现完整的 eSIM 购买与激活流程，但目前仓库中没有提供可访问的 Demo、测试账号或运行截图，程序是否真正实现了核心功能仍缺乏直接证据。在风险应对方面，文档中未看到对技术风险（如支付接口、激活失败处理）的实际验证结果，更多停留在规划层面。需求取舍上，项目提出的功能较多，但 Alpha 阶段尚未明确哪些是已完成的核心需求，哪些是延后实现的次要需求。源代码管理虽然集中，但仓库中 Pull Request 和 CI 构建记录较少，工程过程透明度有待提升。如果由我来领导该小组，我会优先推动“最小可运行版本”的落地，补充详细的构建说明和测试结果，用可运行的程序来支撑项目目标的实现。
如果由我来负责该项目：
在 Alpha 阶段，我会将重点放在“最小可运行版本”的交付上，优先打通搜索、下单和基础激活流程，并提供可复现的 Demo 或测试账号。同时，我会补充完整的 README 文档和构建说明，用可运行的系统来支撑项目目标，而不是仅通过设计描述来说明功能。
第 13 名：team 3 —— 天空外卖系统
优点：
该小组在 Alpha 阶段已经完成了较为清晰的后端工程搭建，采用多模块 Maven 项目结构（sky-common、sky-pojo、sky-server），实现了公共工具、实体模型和业务服务的分层设计，体现了一定的后端架构意识。从工程角度看，这种模块拆分有助于后期系统扩展和代码维护。在项目推进方面，小组不仅停留在功能描述层面，还发布了 Alpha 测试博客，对已有功能进行了验证，说明项目已经进入实际开发和验证阶段，而非纯规划。整体来看，该团队在工程起步和系统结构设计上具备一定基础，为后续功能扩展和系统完善提供了可持续发展的可能性。
缺点与 Bug 分析（≥140 字）：
尽管 team 3 已完成后端初始工程和部分 Alpha 测试，但从程序质量和软件工程角度看，项目仍存在明显不足。首先，目前公开的 Alpha 测试内容主要集中在后端接口和基础功能验证，尚未看到完整的“用户下单—商家接单—配送完成”业务闭环验证，系统是否真正支撑完整外卖流程仍有待进一步证明。其次，仓库中 README 内容较为简略，未提供完整的部署说明、数据库初始化脚本或前后端联调方式，导致项目在新环境中的可复现性较弱。在测试层面，Alpha 测试博客虽有功能验证描述，但缺乏系统性的测试数据（如用例数量、Bug 分类、修复率和回归测试结果），测试深度与覆盖面仍有限。源代码管理方面，目前更多体现为代码提交结果，而缺少对 Bug、任务和需求的 Issue 跟踪记录。如果由我来领导该小组，我会在 Alpha 阶段进一步压缩功能目标，优先打通核心业务闭环，并补充标准化部署说明和更系统的测试报告，以降低后续集成和维护风险。
如果由我来负责该项目：
我会在 Alpha 阶段进一步压缩功能目标，优先打通“用户下单—商家接单—配送完成”的最小业务闭环，并通过接口测试验证各环节的数据一致性。同时，我会补充标准化的部署说明和系统化测试报告，使项目在工程复现性和质量评估方面达到 Alpha 阶段的基本要求。
五、复审总结
通过本次 Alpha 阶段项目复审可以看出，各团队在程序实现与软件工程实践方面均有不同侧重。排名靠前的项目普遍具备 功能闭环清晰、工程规范性较强、风险意识明确 的特点，而排名靠后的项目则多存在 目标过大、工程落地不足或测试深度不够 的问题。
本次复审不仅是对其他团队项目的评价过程，也是一次对软件工程方法与实践的再理解。
浙公网安备 33010602011771号