个人博客3 - 学期总结与反思

作者：陈家驹
日期：2025年12月17日
课程：现代软件工程

经过大半学期的实践，从 Alpha 阶段到 Beta 阶段，从个人项目到团队项目，从理论学习到工程实践，我对软件工程有了更深入的理解。现在，让我回答学期初提出的问题，并分享新的思考。

一、回答学期初的问题

参考博客：现代软件工程阅读与课程反馈：五个问题

1. 课程项目是否需要”只掌舵不下桨”的 PM？

学期初的困惑：PM 的最小投入边界如何定义（只写 Spec/评审/节奏？）以及量化验收如何设定（里程碑准入、被牺牲维度写入 Rubric）。

我的回答：

经过 Alpha 和 Beta 两个阶段的实践，作为 NewsMind 项目的 PM，我深刻体会到：PM 确实需要”掌舵”，但完全”不下桨”在小团队中是不现实的。

实际经验：

Alpha 阶段：我承担了约 30% 的编码工作（CI/CD、集成测试、部署脚本），同时负责项目管理。结果：项目按时交付，但部分技术决策（如数据库选择）在后期才统一，存在一些返工。
Beta 阶段：我减少了编码工作（约 20%），更多时间用于协调、评审、风险管控。结果：技术决策更早统一（如数据库迁移、连接池架构），项目进度更可控。

最小投入边界：

✅ 必须做：需求分析、任务分解、进度跟踪、风险识别、接口规范冻结、集成测试组织
✅ 应该做：代码审查、技术决策协调、跨模块问题解决
⚠️ 可以少做：具体功能编码（除非紧急或无人负责）

量化验收：

我们采用了 DoR（Definition of Ready）机制：任务开始前必须满足需求明确、接口规范冻结、依赖清晰
里程碑准入标准：功能冻结、测试通过、文档更新、部署成功
被牺牲维度：在 Beta Postmortem 中明确记录（如偏好设置模块复杂度评估不足，导致工时增加 8h）

结论：PM 在小团队中需要”掌舵为主，下桨为辅”，关键是明确边界和量化验收。完全不下桨会导致技术决策滞后，完全下桨会导致方向失控。

2. Persona 何时”下线”？是否需要可操作的撤换门槛？

学期初的困惑：课程周期有限下，样本量与判定阈值如何取舍（是否以 5 人可用性 + 关键日志事件为最低证据）。

我的回答：

实际经验：

我们在 Alpha 阶段定义了典型用户（18-40 岁的新闻读者、学生、从业者），但在 Beta 阶段通过真实用户反馈（15 位用户，NPS = 66）验证了 Persona 的有效性。
关键发现：用户反馈与 Persona 高度一致（”真的懂我”、”像跟朋友聊天”），说明 Persona 设计合理。

撤换门槛：

✅ 可用性测试：关键任务 2 次失败 + 1 次可复现场景 → 触发 Persona 撤换
✅ 用户反馈：NPS < 30 或关键功能使用率 < 20% → 触发 Persona 重新评估
✅ 日志事件：关键行为路径完成率 < 50% → 触发场景重构

课程周期限制下的实践：

我们采用了最小可行验证：5 人可用性测试 + 关键日志事件分析
在 Beta 阶段，通过用户反馈验证了 Persona 的有效性，无需撤换

结论：Persona 需要可操作的撤换门槛，但在课程周期有限的情况下，最小可行验证（5 人可用性 + 关键日志）是可行的。关键是持续验证，而不是”写而不用”。

3. 规格说明如何与代码”同源”？Docs-as-Code 的最低实践是什么？

学期初的困惑：在资源受限的课堂，最低可行清单如何定：必做项与可选项的边界。

我的回答：

实际经验：

Alpha 阶段：Spec 和代码分离，导致接口变更时文档滞后，出现”各说各话”的情况。
Beta 阶段：我们采用了 Docs-as-Code 的最低实践：
- ✅ Spec/验收用例与代码同库（Markdown + PR 评审）
- ✅ API 文档自动生成（从代码注释生成）
- ✅ CI 跑单测 + 一条端到端冒烟测试

最低可行清单：

✅ 必做项：
- API 接口规范（Markdown）与代码同库
- 验收用例（Given-When-Then）与测试代码同库
- PR 评审时同步更新文档
✅ 可选项：
- 自动生成 API 文档（如有工具支持）
- 链接校验（如有 CI 支持）

实际效果：

✅ 接口变更时文档同步更新，减少”各说各话”
✅ 验收标准写成测试，减少理解偏差
⚠️ 但文档更新仍需要人工触发，未完全自动化

结论：Docs-as-Code 的最低实践是可行的，关键是同库管理和PR 评审同步。完全自动化需要更多工具支持，但在课程周期内，最低可行清单已经足够。

4. 为避免”委员会设计”，是否引入”单一线程领导（STL）”机制？

学期初的困惑：教学场景如何兼顾收敛与不独断；考核是否纳入”决策质量 + 复盘”。

我的回答：

实际经验：

Alpha 阶段：采用”委员会设计”，所有成员参与所有决策。结果：决策速度慢，部分技术选型（如数据库选择）在后期才统一。
Beta 阶段：我们引入了特性 Owner 机制（类似 STL）：
- 数据库架构升级：姜厚丞（后端）为 Owner，收集意见后独立判断
- 搜索算法优化：林伟权（AI/搜索）为 Owner，负责技术决策
- 前端架构重构：方羿（前端）为 Owner，负责 UI/UX 决策
- 项目管理与集成：我（PM）为 Owner，负责整体协调

兼顾收敛与不独断：

✅ 书面优先：关键决策先写文档，再讨论
✅ 沉默阅读：PR 评审时先阅读，再评论
✅ 结果负责：Owner 对决策结果负责，在 Postmortem 中复盘

考核纳入”决策质量 + 复盘”：

我们在 Postmortem 中明确记录了技术决策的复盘（如数据库迁移、连接池架构）
在团队贡献分评估中，考虑了技术决策的质量（如姜厚丞的数据库架构升级获得高分）

结论：STL 机制在小团队中是有效的，关键是明确 Owner和结果负责。教学场景下，通过 Postmortem 复盘和贡献分评估，可以兼顾收敛与不独断。

5. 早期高不确定性下，如何把”混乱”拉回”复杂”？

学期初的困惑：Spike 的验收物应包含哪些（实验日志、对齐结论、保留/弃用决策）才算达标。

我的回答：

实际经验：

Alpha 阶段：数据库选择（MongoDB vs SQLite）存在不确定性，我们采用了一周 Spike + 可回滚原型：
- 限定时长：1 周
- 影响面：仅数据库层
- 回滚成本：低（可快速切换）
Beta 阶段：数据库迁移（MongoDB → SQLite）采用了受控试错：
- 假设：SQLite + 连接池 + WAL 模式可以满足性能需求
- 实验：实现连接池架构，进行性能测试
- 度量：性能提升 30-40%，并发稳定性提升
- 学习：数据库架构从”脚本式”升级为”基础设施级”

Spike 验收物：

✅ 实验日志：记录假设、实验过程、结果
✅ 对齐结论：团队对齐技术选型
✅ 保留/弃用决策：明确是否采用
✅ 回滚方案：如有问题，如何回滚

实际效果：

✅ 通过 Spike，我们成功将”混乱”（数据库选择不确定）拉回”复杂”（SQLite + 连接池架构）
✅ 验收物完整，便于后续复盘

结论：Spike + 可回滚原型是有效的，关键是限定时长、影响面、回滚成本。验收物应包含实验日志、对齐结论、保留/弃用决策，才算达标。

二、未得到回答的问题与新的困惑

1. 未得到完全回答的问题

问题 1：PM 的最小投入边界如何精确定义？

现状：通过实践，我理解了”掌舵为主，下桨为辅”，但精确定义仍需要更多经验。
困惑：在不同规模团队、不同项目阶段，PM 的投入边界是否应该动态调整？如何量化？

问题 2：Persona 撤换门槛的样本量如何平衡？

现状：我们采用了 5 人可用性测试，但统计显著性仍不足。
困惑：在课程周期有限的情况下，如何平衡样本量与统计显著性？是否有更轻量级的验证方法？

2. 新的困惑

困惑 1：AI 辅助开发的质量如何保障？

我们使用了 Cursor AI 辅助代码审查，但AI 生成代码的质量如何系统化评估？
如何避免 AI 生成的代码引入隐藏的技术债？

困惑 2：敏捷开发在课程周期内的适用性？

10 天 Sprint 在课程周期内是可行的，但长期维护（如正式版）如何平衡敏捷与稳定性？
如何在快速迭代与代码质量之间找到平衡？

三、AI 时代的软件开发：新的问题

经过 Alpha 和 Beta 阶段的实践，特别是使用 Cursor AI 辅助开发后，我对 AI 时代的软件开发有了新的思考：

1. AI 辅助开发的质量保障机制

问题：如何系统化评估 AI 生成代码的质量？如何避免 AI 引入隐藏的技术债？

思考：

需要建立 AI 代码审查清单：逻辑正确性、性能影响、安全风险、可维护性
需要人工审查：AI 生成的代码必须经过人工审查，不能直接合并
需要测试覆盖：AI 生成的代码必须有对应的测试用例

2. AI 与人类开发者的协作边界

问题：在 AI 辅助开发中，人类开发者应该专注于什么？AI 应该承担什么？

思考：

人类开发者：架构设计、技术决策、业务逻辑、代码审查
AI：样板代码生成、接口文档生成、测试用例生成、代码审查辅助
边界：AI 负责”重复性工作”，人类负责”创造性工作”

3. AI 时代的软件工程教育

问题：在 AI 辅助开发普及的背景下，软件工程教育应该如何调整？

思考：

基础能力：算法、数据结构、系统设计等基础能力仍然重要
新能力：AI 工具使用、提示工程、AI 代码审查、AI 辅助测试
教育重点：从”写代码”转向”设计系统”和”保障质量”

4. AI 生成代码的知识产权与责任

问题：AI 生成的代码的知识产权归属？如果 AI 生成的代码出现问题，责任如何划分？

思考：

知识产权：AI 生成的代码应该归属于使用 AI 的开发者
责任：开发者对 AI 生成的代码负有最终责任，需要审查和测试
透明度：需要在代码中标注”AI-assisted”，便于追踪和审查

四、NCL 理想教学环境 vs 实际体验

参考：NCL 的理想教学环境

1. 以公开博客来交作业的方法

理想：通过公开博客，学生可以互相学习，形成”千帆竞发”的学习氛围。

实际体验：

✅ 优点：
- 公开博客确实促进了互相学习，我经常阅读其他团队的博客，学习他们的经验
- 公开博客提高了作业质量，因为”公开”本身就是一种压力
- 公开博客形成了知识沉淀，便于后续查阅
⚠️ 不足：
- 部分学生可能因为”公开”而不敢写真实想法
- 博客质量参差不齐，需要更多引导

价值：⭐⭐⭐⭐⭐（5/5）
差距：基本符合理想，但需要更多引导和激励。

2. 结对编程的 API 驱动的编程

理想：通过结对编程，学生可以学习协作和代码审查。

实际体验：

✅ 优点：
- 结对编程确实促进了协作，我在电梯调度系统项目中体验了结对编程
- API 驱动的编程帮助我理解了接口设计的重要性
⚠️ 不足：
- 结对编程的时间安排较难协调
- API 驱动的编程在课程周期内可能不够深入

价值：⭐⭐⭐⭐（4/5）
差距：基本符合理想，但需要更多时间投入。

3. PQ-问答的当堂测试，对软件 UX 的现场测试

理想：通过当堂测试，学生可以及时反馈，教师可以及时调整。

实际体验：

✅ 优点：
- PQ-问答确实促进了课堂互动
- 当堂测试帮助我及时发现问题
⚠️ 不足：
- 当堂测试的时间可能不够充分
- 软件 UX 的现场测试需要更多用户参与

价值：⭐⭐⭐⭐（4/5）
差距：基本符合理想，但需要更多时间投入。

4. 学生自行组队并选择项目

理想：学生可以根据兴趣组队，选择感兴趣的项目。

实际体验：

✅ 优点：
- 自行组队确实提高了团队凝聚力
- 选择感兴趣的项目提高了学习积极性
- 我们选择了 NewsMind 项目，因为对 AI 和推荐系统感兴趣
⚠️ 不足：
- 部分团队可能因为项目选择不当而遇到困难
- 需要更多指导和资源支持

价值：⭐⭐⭐⭐⭐（5/5）
差距：基本符合理想，但需要更多指导和资源支持。

5. Alpha 阶段后强制团队有人员变动

理想：通过人员变动，学生可以体验不同的团队文化，学习适应能力。

实际体验：

✅ 优点：
- 人员变动确实促进了团队文化的交流
- 我们团队在 Beta 阶段迎来了林伟权，他快速融入团队，带来了新的技术视角
⚠️ 不足：
- 人员变动可能导致项目连续性中断
- 需要更多时间适应新成员

价值：⭐⭐⭐⭐（4/5）
差距：基本符合理想，但需要更多时间适应。

6. 请业界的专家、相关的老师、工程师来讲课 + demo

理想：通过业界专家的分享，学生可以了解实际工作场景。

实际体验：

✅ 优点：
- 业界专家的分享确实开阔了视野
- Demo 展示帮助我理解了实际应用场景
⚠️ 不足：
- 专家分享的时间可能不够充分
- 需要更多互动和问答环节

价值：⭐⭐⭐⭐（4/5）
差距：基本符合理想，但需要更多互动和问答环节。

7. 用”天使投资”的方法来评选成功的团队项目

理想：通过”天使投资”的方法，学生可以体验真实的项目评估过程。

实际体验：

✅ 优点：
- “天使投资”的方法确实提高了项目评估的真实性
- 我们团队在 Beta 阶段通过”天使投资”获得了认可
⚠️ 不足：
- “天使投资”的标准可能需要更明确
- 需要更多反馈和改进建议

价值：⭐⭐⭐⭐⭐（5/5）
差距：基本符合理想，但需要更多反馈和改进建议。

五、对课程的深思熟虑后的感想

参考：现代软件工程 - 2025年秋 - 期中学生总结和反馈（课程反馈文档）

1. 课程设计的价值

“做中学”的理念：

通过实际项目，我深刻理解了软件工程的理论知识
从 Alpha 到 Beta，从个人项目到团队项目，每个阶段都有新的收获
理论 + 实践的结合，让我对软件工程有了更深入的理解

公开博客的价值：

公开博客不仅是一种作业形式，更是一种学习方式
通过阅读其他团队的博客，我学到了很多经验
公开博客形成了知识沉淀，便于后续查阅

2. 课程改进建议

时间安排：

10 天 Sprint 在课程周期内是可行的，但长期维护（如正式版）可能需要更多时间
建议在课程后期留出更多时间用于项目优化和总结

资源支持：

建议提供更多的技术资源支持（如云服务器、API 密钥等）
建议提供更多的学习资源（如技术文档、最佳实践等）

反馈机制：

建议建立更及时的反馈机制，帮助学生及时发现问题
建议在 Postmortem 中提供更多的改进建议

3. 个人收获

技术能力：

掌握了完整的软件开发流程（需求分析、设计、开发、测试、部署）
学会了使用 AI 辅助开发（Cursor AI）
提升了代码质量和工程实践能力

团队协作：

学会了如何作为 PM 管理项目
学会了如何与团队成员协作
学会了如何解决跨模块问题

工程思维：

学会了如何平衡”多、快、省”
学会了如何管理风险
学会了如何持续改进

六、自我评价：课前/课后提高最大的部分

参考：软件工程师能力自我评价表

1. 项目管理能力 ⭐⭐⭐⭐⭐（课前：⭐⭐，课后：⭐⭐⭐⭐⭐）

提高原因：

作为 NewsMind 项目的 PM，我负责了 Alpha 和 Beta 两个阶段的整体规划
学会了任务分解、进度跟踪、风险识别、团队协调
在 Beta 阶段，通过 DoR 机制、API 冻结、GitHub Project 同步，项目管理能力显著提升

具体表现：

✅ 成功协调数据库迁移、连接池架构升级等重大技术决策
✅ 组织团队协作，解决跨模块问题
✅ 在 Postmortem 中获得团队贡献分 97 分（排名第一）

2. 软件工程质量保障 ⭐⭐⭐⭐⭐（课前：⭐⭐，课后：⭐⭐⭐⭐⭐）

提高原因：

在 Beta 阶段，我们建立了完整的质量保障机制（自动 lint、代码审查、E2E 测试）
学会了使用 Cursor AI 辅助代码审查
学会了如何平衡快速迭代与代码质量

具体表现：

✅ 建立了 CI/CD 流程，测试环境验证通过率 100%
✅ 代码质量显著提升，lint 检查自动化
✅ 数据库架构从”脚本式”升级为”基础设施级”

3. 系统架构设计能力 ⭐⭐⭐⭐（课前：⭐⭐，课后：⭐⭐⭐⭐）

提高原因：

在 Beta 阶段，我们完成了数据库架构升级（MongoDB → SQLite + 连接池 + WAL）
学会了如何设计可扩展、可维护的系统架构
学会了如何平衡性能与可维护性

具体表现：

✅ 数据库性能提升 30-40%
✅ 搜索性能优化，缓存命中率提升约 20%
✅ 系统架构从”脚本式”升级为”基础设施级”

4. 团队协作能力 ⭐⭐⭐⭐⭐（课前：⭐⭐⭐，课后：⭐⭐⭐⭐⭐）

提高原因：

作为 PM，我学会了如何与团队成员协作
学会了如何解决跨模块问题
学会了如何平衡个人贡献与团队协作

具体表现：

✅ 成功协调前后端、AI 模块的集成
✅ 解决了数据库迁移、偏好设置等跨模块问题
✅ 在 Postmortem 中获得团队贡献分 97 分（排名第一）

5. 问题解决能力 ⭐⭐⭐⭐（课前：⭐⭐⭐，课后：⭐⭐⭐⭐）

提高原因：

在 Alpha 和 Beta 阶段，我们遇到了很多技术难题（反爬、数据库性能、搜索优化等）
学会了如何系统化分析问题、提出解决方案、验证效果
学会了如何从失败中学习（Postmortem 复盘）

具体表现：

✅ 解决了反爬问题，引入代理池策略
✅ 解决了数据库性能问题，引入连接池 + WAL 模式
✅ 解决了搜索性能问题，引入 FTS5 全文搜索

七、总结

经过大半学期的实践，我从学期初的”五个问题”出发，通过 Alpha 和 Beta 两个阶段的实践，对软件工程有了更深入的理解。虽然部分问题仍未完全回答，但实践过程本身就是最好的答案。

最大的收获：

✅ 掌握了完整的软件开发流程
✅ 提升了项目管理和团队协作能力
✅ 学会了如何平衡”多、快、省”
✅ 学会了如何持续改进

未来的方向：

继续深入学习软件工程的理论知识
在实际工作中应用所学知识
持续关注 AI 时代的软件开发趋势

感谢：

感谢老师的悉心指导和课程设计
感谢团队成员的支持和协作
感谢所有帮助过我的同学和助教

项目地址：https://z.gitee.cn/zgca/NewsMind.git
在线体验：https://pipiplus.site/
发布视频：https://b23.tv/ceHLGT9

最后更新：2025年12月17日