软件工程 Alpha 阶段项目复审报告
团队作业6——Alpha 阶段项目复审报告
复审团队： 没活硬整团队
复审人： 谢斯越、郑哲磊、李靖华、温尚熙
复审时间： 2025-12
一、 复审综述与评价准则
作为“没活硬整团队”，我们在本次 Alpha 阶段复审中不仅关注各组代码的“增删改查”功能是否实现，更将视角拔高到工业级软件工程的高度。我们评估的核心逻辑遵循软件工程经典公式：
其中，程序质量关注并发稳定性、安全性、用户体验；软件工程质量则侧重于开发过程的透明度（Scrum 执行）、质量保障（自动化测试）以及风险管控（需求取舍）。以下是我们对 8 个复审项目的深度解析。
二、 各团队项目执行细节深度阐述
1. 带派不队 —— iBlog Community 多用户博客社区
GitHub 仓库: WorkingBlog
该团队是本次 Alpha 阶段中“工程纪律”的执剑者。他们不仅在技术架构上选择了 Vue3 组合式 API 与 SpringBoot 的现代组合，更引入了 Elasticsearch 解决了深层次的文本检索性能问题。
- 架构亮点： 实现了真正的 CI/CD 流水线，代码提交即触发自动化构建与测试，这在学生项目中极具前瞻性。100% 的单元测试覆盖率证明了他们对“代码即资产”的严谨态度。
- 潜在隐忧： 团队陷入了典型的“技术乌托邦”。在复审中我们发现，虽然底层逻辑严密，但在高频点击点赞或评论时，后端出现了非原子性的计数更新，这反映了在高并发一致性处理上的经验缺失。此外，项目缺乏真实世界的流量洗礼，过度优化的架构在某种程度上超前于当前的业务需求。
2. KFCoder —— 日常健康打卡系统
Gitee 仓库: kfcoder
KFCoder 团队展现了极其卓越的测试驱动开发（TDD）倾向。他们构建了一套横跨前端 UI（Selenium）与后端 API（Pytest）的自动化测试矩阵，这是确保 Alpha 版本稳定性的“压舱石”。
- 工程规范： Gitee Issues 的使用效率极高，每一个 Bug 修复都对应着清晰的任务看板，实现了开发过程的可追溯性。
- 核心短板： 项目最大的风险在于“核心价值的稀释”。Alpha 阶段承诺的“智能健康伴侣”目前仅体现为简单的 IF-ELSE 逻辑判断，缺乏真正的数据驱动反馈。如果 Beta 阶段不能引入基础的统计学模型或预测算法，该项目可能会沦为一个平庸的表单填充器。
3. 东拼西凑 —— 云档集成管理平台 (DPXCYun)
GitHub 仓库: YunPan
该团队在项目管理透明度上表现优异。他们利用 WBS（工作分解结构）和 PERT 图动态调整进度，这种“管理驱动”的模式有效规避了 Alpha 阶段常见的进度失控风险。
- 文档价值： 发布的 Release Notes 具有工业级水准，详尽介绍了环境依赖与配置陷阱，降低了用户的复现门槛。
- 功能落差： 令人遗憾的是，云盘的核心命脉——断点续传，在本次交付中仅停留于文档设计层面。分片上传逻辑的缺失意味着在网络环境波动时，用户体验将极速下滑。此外，本地化部署限制了“外链分享”这一社交属性的真实闭环。
4. 蛋仔派队 —— 体育场馆预约系统
GitHub 仓库: Sports_Venue_Reservation_System
蛋仔派队是班级中少有的重后端、重压测团队。他们通过 200次/分钟的压力测试数据，证明了系统在应对选场高峰时的韧性，并合理引入了数据库事务回滚机制。
- 逻辑韧性： 解决了预约系统的“超卖”问题，后端权限校验逻辑覆盖了管理员与普通用户的多种边界场景。
- 交互硬伤： 前端工程化程度相对较低，缺乏对业务边界的强约束（如允许选择已过去的时间节点进行预约）。Git 协作模式略显原始，主分支直接推送的行为增加了代码冲突与逻辑污染的风险，缺乏 Feature 分支的演进过程。
5. coding小分队 —— 图书管理系统
GitHub 仓库: library-system
该团队精准地切入了校园图书管理的高频痛点，技术选型极其务实（SpringBoot + Redis + JWT）。他们对 RBAC 权限模型的实现非常到位，确保了不同角色操作的安全性。
- 业务适配度： 系统逻辑严丝合缝地贴合了现实中图书馆的借还书流程，Redis 缓存的引入有效缓解了热门书目的查询压力。
- 交付广度： 团队在功能铺开上过于分散，导致核心借还流程的异常边界测试不足。README 文档对非开发者极不友好，缺乏一键初始化数据库的脚本，这反映了在“可交付性工程”上的缺失。
6. NoteForces —— 简易在线笔记系统
GitHub 仓库: noteforces
NoteForces 在产品美学与交互一致性上表现突出。他们利用 Markdown 实时渲染引擎和响应式布局，打造出了极佳的跨平台书写体验。
- 产品亮点： 分类标签与笔记检索的响应速度极快，体现了前端状态管理的精心设计。
- 稳定性预警： 笔记系统的头号天敌是“数据丢失”，而该系统目前缺乏静默自动保存机制。在模拟断网或浏览器崩溃的复审测试中，未保存的文本无法找回。此外，处理万字长文时出现的渲染掉帧现象，反映了前端虚拟滚动技术的缺位。
7. 哥们废了 —— 哥们记了（账单分析/健身记录）
GitHub 仓库: ge-men-ji-le
该团队走的是高效迭代、差异化竞争的路线。他们利用 Django 的脚手架优势快速搭建了逻辑层，并使用 Pandas 进行数据清洗，实现了多维度的可视化洞察。
- 交付效率： 团队以极小的人力代价换取了最高的功能完成度，这种对框架的驾驭能力值得学习。
- 鲁棒性隐患： 账单分类算法过于脆弱，高度依赖固定关键词匹配。复审中输入非标准格式的 CSV 文件时，系统频繁报错且提示信息晦涩。这说明团队在异常处理和用户引导逻辑上还处于较低水平。
8. TanhT —— 高校开发者博客系统
GitHub 仓库: TanhT-backend
TanhT 团队在需求工程与愿景规划层面达到了准专业水准。其输出的 User Story 和系统架构设计图具备极高的逻辑深度，体现了对开发者社区生态的深刻思考。
- 文档标杆： 需求规格说明书中的场景挖掘非常深入，甚至考虑到了知识图谱在博客关联中的应用。
- 严重失真风险： 遗憾的是，其代码实现与文档规划存在严重的“两层皮”现象。Alpha 阶段交付的版本基本是一个纯前端的交互 Mock，核心后端持久化与索引功能几乎缺失。这种“只有表皮、没有骨架”的交付状态，使其在软件工程的真实性评分上处于劣势。
三、 Alpha 阶段项目综合复审汇总表
| 小组名字与链接 | 核心优点 | 关键缺陷与 Bug 深度报告（具体分析） | 最终名次 |
|---|---|---|---|
| 带派不队 GitHub 链接 |
技术选型很新，测试覆盖率 100% 极其恐怖，CI/CD 流程走得很全。 | Bug 报告： 在我们进行并发压力测试时，发现点赞功能存在竞态条件。比如两个人同时给一条博客点赞，由于后端没有使用原子操作或分布式锁，最终计数只增加了 1 而不是 2。此外，JWT 权限验证没做过期刷新逻辑，用户一掉线就得重登。从工程角度看，这组太沉迷于技术指标，导致一些基础的用户交互细节被忽略了，比如评论后的实时刷新偶尔失效。 | 1 |
| KFCoder Gitee 链接 |
自动化测试体系非常成熟，已经部署到云端可供实时访问。 | Bug 报告： 系统的“健康打卡建议”完全是死逻辑，并没有体现出宣称的 AI 特性。最严重的工程问题是安全性：数据库明文密码直接传到了 Gitee 公开仓库，这在软件工程中是极大的风险。另外，部署脚本对不同环境的兼容性较差，我们在 Ubuntu 以外的环境尝试部署时遇到了大量的路径报错，文档里也没写清楚依赖库的版本要求。 | 2 |
| 东拼西凑 GitHub 链接 |
团队管理非常规范，进度控制和 Bug 分类管理做得很有条理。 | Bug 报告： 云盘的核心承诺“断点续传”没能兑现，导致大文件上传极度不可靠。分享链接功能在本地环境运行正常，但因为没做内网穿透或公网部署，在复审环节无法验证其多用户协作的价值。代码库里发现很多未使用的冗余组件，导致前端包体积过大。工程上表现为“文档很丰满，程序很骨感”，核心技术攻关在 Alpha 阶段其实是失败的。 | 3 |
| 蛋仔派队 GitHub 链接 |
后端并发控制做得很好，有真实的压测数据支撑系统稳定性。 | Bug 报告： 前端逻辑校验几乎处于裸奔状态。我们发现不仅能预约过去的日期，甚至能通过修改 API 参数实现“负数金额”预约，后端没做严谨的范围校验。Git 协作很不规范，代码提交记录非常随意，甚至有直接在 Master 分支修改代码的情况。这组需要在 Beta 阶段加强前后端联调的逻辑一致性，并把 Git 分支管理强制执行起来。 | 4 |
| coding小分队 GitHub 链接 |
业务模型很成熟，权限校验和 Redis 缓存的使用比较到位。 | Bug 报告： 系统在处理大量图书数据时的检索性能没有经过验证，我们用脚本灌入 1 万条数据后，查询耗时显著增加，说明索引设计有问题。README 文档严重缺失，没有数据库 SQL 脚本，没有依赖环境说明。作为一个图书系统，连最基本的“一键借书”功能在某些边界条件下（如超期未还时再借）会产生逻辑死锁，导致程序崩溃。 | 5 |
| NoteForces GitHub 链接 |
界面设计美观，Markdown 编辑器适配做得很好，支持多端使用。 | Bug 报告： 没有自动保存机制是最大的雷点。用户在编辑过程中如果不手动点击保存，一旦浏览器崩溃或网速波动导致连接断开，所有数据都会丢失。长文本下的性能优化也没做，字数超过五千字后，打字会有明显的跟手延迟。另外，删除分类时没提示用户该分类下的笔记会去哪，导致我们测试时出现了一堆“孤儿笔记”找不到入口。 | 6 |
| 哥们废了 GitHub 链接 |
利用 Django 高效完成了核心闭环，报表分析的可视化效果不错。 | Bug 报告： 文件导入模块的鲁棒性极差，CSV 文件只要多一个空格或少一个逗号，后端直接抛出 500 错误。分类引擎无法学习用户行为，每次同样的错误分类都要用户手动纠正，交互非常累赘。工程上缺乏单元测试，我们改动了其中一个数据处理逻辑后，发现导致了后面好几个图表显示异常，说明代码耦合度太高，维护起来非常痛苦。 | 7 |
| TanhT GitHub 链接 |
需求分析极其深入，UI 原型图设计得非常漂亮，产品定位很准。 | Bug 报告： 这个项目目前还不能被称为“软件”，因为它没有后端数据支撑。所有数据都是临时存放在内存里的，只要用户刷新一下浏览器，之前写的所有内容全部清空。规划中的全文检索、知识图谱等硬核功能在当前代码库里完全找不到实现的痕迹。这组属于典型的“过度设计”，花了 90% 的精力写文档画图，只花了 10% 的精力写代码。 | 8 |
四、 复审总结与通用建议
作为没活硬整团队，通过对上述 8 个项目的深度复审，我们认为：Alpha 阶段是“骨架”与“血液”的博弈。 优秀的团队已经完成了自动化流水线的构建（骨架），而暂时落后的团队则在纠结于 UI 美化（皮肤）。
1. 通用技术改进方案
- 消除“孤岛开发”： 建议所有团队在 Beta 阶段摒弃“本地演示”，全面转向云端交付（Docker 容器化）。
- 强化防御性编程： 必须在前端和后端同时建立校验屏障。不要相信任何用户输入，也不要假设网络永远通畅。
- 重视数据一致性： 对于预约、借书、记账等涉及数字增减的功能，必须在数据库层面使用事务锁或在应用层使用 Redis 原子操作。
2. 软件工程流程优化
- Git 规范化： 严禁直接推送 Master 分支，建议采用 PR（Pull Request）评审机制，至少由一名队友 Review 代码后再合并。
- 真实用户闭环： 走出寝室，找 3-5 名真实用户试用系统。他们发现的易用性 Bug 往往比单元测试发现的逻辑 Bug 更有价值。