不鸽工程队 —— α 阶段问题总结随笔（事后诸葛亮）

2026-11-12 21:02:55 37 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

有关SPSS中Fisher精确检验无法进行的解决方法（由于无法打开临时文件，因此无法进行计算）最近在帮一个四年生完成她的毕业论文，在用SPSS进行R×C表检验的时候，发现Fisher精确检验的结果无法显示，提示为“由于无法打开临时文件，因此无法进行计算”，大概像下图一样。（这图是从网上找的）然... 阅读详情

不鸽工程队 —— α 阶段问题总结随笔（事后诸葛亮）

项目	内容
这个作业属于哪个课程	202601-福大-软件工程实践-W班
这个作业要求在哪里	团队作业—Beta冲刺+事后诸葛亮
这个作业的目标	以"事后诸葛亮"会议形式复盘 α 阶段（2026.10.23-10.29）在设计实现、测试发布、变更管理、团队协作、目标计划五类问题上的得失，为 β 冲刺立规矩
其他参考文献	邹欣.《构建之法：现代软件工程》（第4版）

不鸽工程队 —— α 阶段问题总结随笔（事后诸葛亮）
一、复盘方式
二、设计/实现相关的问题
三、测试/发布相关的问题
四、变更管理；团队的角色、管理、合作相关的问题
4.1 变更管理
4.2 角色与管理
五、设想和目标；计划相关的问题
六、值得保留的做法（复盘不只挑毛病）
七、结语

一、复盘方式

全组于 β 冲刺开始前开了一次线上总结会。规则只有一条：只摆事实和根因，不追究个人。α 阶段的七篇日报、36 项自测记录、答辩 PPT 和代码仓库本身，就是我们的"案发现场"。会后产出三样东西：本篇总结、《凡事预则立》规划、以及一套写进仓库的《代码规范》。

二、设计/实现相关的问题

这是问题最密集的一类。核心教训一句话：设计文档写了 ≠ 实现了，答辩讲了 ≠ 跑得通。

#	问题	具体表现	根因	β 对策
1	活动状态机断链（最严重）	全库没有任何代码把 `activity.status` 置为 2(已满员) 或 3(已结束)；而"放鸽子扣分"定时任务只扫 status=3 → α 宣称的核心差异化功能在真实运行中永远不会触发，只能手动改库演示	前端用 `current_people >= max_people` 自己算了"满员"视觉效果，看起来像做完了；状态流转没有明确的负责模块	β Day1 优先补状态机：满员自动置 2、过期自动置 3，打通"扣分→降级→限制报名"完整链路
2	四维筛选只落地了半维	后端仅支持类型+时间区间+状态；地点、标签、关键词筛选都没有。前端广场是循环 5 次按类型拉全量再内存拼装，"为你推荐"是前端本地打分而非后端 `/recommend` 接口	冲刺时间紧，前端用"视觉凑合"顶替了后端能力，且没有记录到任务清单里	β 补全后端筛选参数与推荐接口，前端改为一次请求
3	通知 type 字典三方不一致	建表脚本注释 1-6 种类型，后端实体常量只用了 1-4，链路自洽但和数据库设计说明书对不上	两个模块并行开发，字典没有单一事实来源	β 统一字典并回写文档
4	取消活动不通知已报名用户	后端有逻辑删除，但级联通知缺失，需求文档明确要求过	只实现了"删"，没实现"善后"	β 补取消→退名额→发通知的级联逻辑
5	设计模式是"纸面设计"	设计说明书里的排序策略接口、`BaseService.executeTransaction` 模板方法、`ActivityDetailVO.Builder` 在代码中都不存在	文档写于编码之前，编码时未回头对齐；答辩前未核对	β 要么落地要么诚实回写文档，不再保留"两套说法"
6	重复代码	两套 `Result` 返回类（code=200 与 code=0）、两套 `Activity` 实体、两个 `UserProfileMapper`	人员变动后组长救火重写，旧实现未清理	β 统一为一套并删除死代码
7	安全欠账	`/api/dev/token?userId=N` 后门仍可伪造任意用户登录；`application.yml` 明文提交数据库密码；实名信息（姓名/学号）未按需求做 AES 加密，明文入库	开发后门方便联调后忘了删；密码管理靠自觉	β 第一周内：删后门、密码改环境变量、实名字段加密存储

这一类的元问题：α 的"完成"标准是"界面上能看出来"，而不是"数据流上可验证"。很多功能是前端把后端缺的东西在视觉上圆过去了 —— 这在演示时看不出来，但经不起评审追问数据从哪来。

三、测试/发布相关的问题

#	问题	具体表现	根因	β 对策
1	测试全靠人工复制粘贴	AI 生成用例后，组员在 Apifox 里一条条手动执行、手动贴结果。回归一次全量用例要半小时起步，于是实际上很少回归	没有把"可重复"作为测试脚本的设计目标	β 核心改进（答辩点名项）：全组统一用 WorkBuddy 把核心用例改造成自动化脚本（接口级），提交即回归，测试报告自动生成
2	测试职责后置	前 4 天测试岗实际空转（人员缺勤），测试集中压在第 5-6 天	关键路径上只有一个测试人力，无备份	β 测试负责人 Day1 就建自动化框架，不再"开发完了才开始测"
3	环境漂移	云端后端一度是旧版本，排序修复在本地生效、线上无效；云服务器到期回收风险未提前确认	缺少"部署即最新"的检查步骤	β 合并 master 后固定执行"打包→上云→冒烟"三步，并在随笔里留部署记录
4	错误码认知混乱	前端一度把 5000（系统异常）当参数错误排查，浪费半天；真正原因是 JWT 里的 userId 不存在触发外键失败	5000 是兜底码，掩盖了真实异常类型	β 梳理错误码语义表进 Apifox，前端按 code 分支处理
5	E2E 发现的价值被低估	同秒排序不稳定这种 bug，只有拉起真实数据库跑全链路才能发现 —— 但 E2E 直到 Day6 才做	单测和黑盒都测不出"环境齐备时的时序问题"	β 把 E2E 冒烟（注册→发布→报名→消息）纳入每日自动化回归
6	并发与边界测试规模不足（评审指出）	α 只做过一次"60 并发抢 19 名额"，测试数据量停留在百级；边界用例只覆盖报名单点，没有系统化矩阵	把"能跑通"当成"测到位"：没有造数夹具，也没有压测方案设计	β 造数 1000 用户 / 500 活动 / 5000 报名；分档压测 100 / 500 / 1000 并发（实时监控死锁、超卖、幂等）；建数值/时间/信用/权限四类边界矩阵并逐条执行

四、变更管理；团队的角色、管理、合作相关的问题

4.1 变更管理

#	问题	具体表现	根因	β 对策
1	人员变动没有预案	核心组员前期缺勤 3 天，用户/活动模块空壳，无 JWT → 全组联调 401 卡死，进度一度落后 8 个点	关键路径单人负责，无备份、无代码盘点机制	β 每个模块指定"第一负责人+了解程度第二的人"；模块代码随时保持"另一个人能看懂"的注释水平
2	master 直推，无 review	全员直接 push master，51 个提交无一次评审记录	求快；没有意识到规范本身的问题	β 已改：master 保护 + feature 分支 + MR 由组长统一合并（老师答辩意见）
3	接口契约靠喊	字段名 phone/account 不一致、路径 /activity/list 与 /api/activities 打架、前端 404 后静默降级 mock 导致 Profile 页永远显示假数据	Apifox 有文档但没人把它当"唯一真相"，改动不走文档	β 立规矩：改接口先改 Apifox，MR 描述必须附文档链接；前端禁止 catch 里静默降级 mock（至少 console.warn + 随笔记录）
4	文档与代码漂移	设计文档 V2.0 与实现脱节（见第二节问题 2/3/5）	文档写完就归档，没有随代码更新	β 每日站会留 5 分钟对文档，变更当天回写

4.2 角色与管理

#	问题	具体表现	根因	β 对策
1	组长单点过载	李佳同时承担统筹+信用模块+救火重构两个模块+运维+汇报，贡献度 37% 远超他人	危机时刻只能组长兜底，但说明日常就没有风险分摊	β 模块归属正式化（用户/活动/信用归李佳，报名/消息归林严泽），不靠临时补位
2	贡献度失衡	37% / 27% / 24% / 14%，末位成员β阶段更换	激励与督促机制缺位，问题拖了 4 天才升级	β 每日随笔公开记录每人 commit 数与产出，问题当天暴露
3	AI 工具五花八门	全组用过 DeepSeek、通义灵码、豆包、Seed-Code、WorkBuddy 五种工具，经验无法沉淀，产出质量参差	没有统一选型（α 答辩被点名）	β 全组统一 WorkBuddy：编码、测试自动化、文档生成都在同一工具链上，组内沉淀共享 Prompt 库
4	编码规范靠事后补救	BOM 头导致编译失败、两套 Result 并存、Mapper 同名撞 Bean	无代码规范文档，无提交前检查	β 发布《代码规范》（含 Git 分支/commit message 规范），MR review 按规范打回

五、设想和目标；计划相关的问题

#	问题	具体表现	根因	β 对策
1	目标定得太大	需求文档 21 条验收标准，7 天冲刺全压上去，结果核心闭环之外的功能（验证码、资料修改、取消活动）全部延期	没有做 MVP 分级，默认"全都要"	β 明确 P0/P1/P2 串行：先把 α 的欠账（状态机、筛选、安全）清完，再谈新功能
2	估点过于乐观	"满员自动截止""定时扣分"按 1-2 点估算，实际因状态机断链等于 0 分完成	估点只看代码量，不看数据流完整性	β 估点必须回答"这个功能的数据从哪张表来、被谁更新"
3	任务总量变化没有记录	燃尽图只有剩余点数，α 中途发现的新任务（如死锁修复、密码兼容）没有体现在总盘子里	缺少 backlog 变更记录	β 每日随笔增加"任务总量变化"小节，新发现的任务当天入账
4	缓冲不足	Day7 全部用于物料，没有留真正的回归缓冲	燃尽计划排满到 deadline	β 预留 Day7 整天做全量回归与答辩演练，不允许排新功能

六、值得保留的做法（复盘不只挑毛病）

每晚 21:00 站会：问题不过夜，Day3 的危机正是靠站会当天暴露、Day4 才能反转 —— 保留；
乐观锁+唯一索引防超卖：60 并发零超卖，且唯一索引作为"并发安全最后防线"的设计是对的 —— 保留；
Spring Event 异步落库：主流程与通知解耦，方向正确 —— 保留；
公网环境开发：从 Day5 起所有联调在真实公网做，跨域/权限问题提前暴露 —— 保留；
诚实标注完成度：答辩 PPT 把"降级/延期"如实写出，虽被追问但赢得了信任 —— 继续坚持。

七、结语

α 阶段我们最大的收获不是那个能跑的系统，而是看清了三个真相：人员的单点是最大的工程风险，"看起来做完了"和"数据流跑通了"是两回事，AI 很强但没有统一的工作流就只是玩具。 这三条直接决定了 β 阶段的全部改进项 —— 状态机优先补链、自动化测试落地、全组统一 WorkBuddy、分支与评审制度上墙。

...全文