[I.3] 个人作业：结课总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2026春季软件工程 |
| 这个作业的要求在哪里 | [I.3] 个人作业：结课总结 |
| 我在这个课程的目标是 | 学习软件的系统开发流程，通过团队合作完成软件 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾课程总结经验 |
提问博客：[I.1] 个人作业：阅读和提问。
链接：https://www.cnblogs.com/wyj26/p/19701352
一、回到学期初的问题
问题一：工期如何合理预估？
原问题： 新手没有历史数据，怎么科学预估工期？
解答： 通过实践摸索出"拆解 + 锚定 + 修正"三步法。
- 拆解：把"学习时间"和"执行时间"分开算。T1预估60-90分钟，实际断断续续做了2天（4月3日到4月5日），大部分时间耗在学AssemblyScript语法和搭Wasm环境上，编码本身反而没花多久。
- 锚定：用相对估计替代绝对估计。比如"实现邮箱注册比AI聊天简单一半"，比直接说"3小时"更靠谱。
- 修正：靠PSP表格记录实际耗时。结对项目预估600分钟，实际735分钟，这个偏差就是下次预估的校准依据。
问题二：探索与结对如何平衡？
原问题： 学生项目都在学新技术，先独立学还是直接结对？
解答： 通过实践发现"交替模式"最有效。
先各自花30分钟独立看文档，标记不懂的地方，再一起讨论难点。T3时演变为：独立探索方案 → 结对讨论可行性 → 独立编码 → 结对Code Review。探索是个人的事，但转化为团队共识需要协作。
问题三：汉堡包反馈法好不好用？
原问题： 快节奏开发中，汉堡包反馈会不会让表达不清晰？
解答： 我认为这需要看场景来分析。
- 结对项目（2-3人，高信任）：直接反馈效率高，搭档说"参数顺序错了"就行。
- 团队项目（6人，信任参差不齐）：书面Code Review用汉堡包法（先肯定再指出问题），口头沟通用直接反馈（语气表情能缓冲）。奈飞的直接文化建立在高信任基础上，不一定适合所有团队。
问题四：主治医师模式怎么用？
原问题： 成员能力不均时，如何避免"一人干活其他人打酱油"？
解答： 通过团队项目的实践试错找到"轮转主治医师"模式。
每个模块由不同的人当主治（方案设计+核心编码），其他人当助手（测试+文档）。这样每个人都有机会主导，也有机会学习。关键是避免"角色固化"——一直让强者当主治，差距会越来越大。
问题五：回归测试怎么高效做？
原问题： 每次改代码都要重测所有旧功能吗？自动化测试怎么实现？
解答： 通过实践总结出三个层次：
- 手动回归：列核心功能的冒烟测试清单，每次大改动后跑一遍。
- 自动化核心逻辑：结对项目用
test.js自动验证判定逻辑，campus后端用pytest覆盖API端点，几秒钟跑完。 - CI/CD集成：campus配置GitHub Actions，每次push自动运行测试。
对学生来说，第2层性价比最高——不用搭CI环境，又能及时发现回归问题。
二、原来的问题，还有没有没弄明白的？
问题一（工期预估）： 虽然有了"拆解+锚定+修正"方法，但第一次预估还是很难靠谱。T1偏差超过7倍，campus Alpha阶段也时间失控。这是新手的固有局限——没有足够样本量校准预估模型，可能需要多个项目积累才行。
问题四（主治医师模式）： "轮转主治"假设每个人至少在某个领域能当主治。如果团队中有"任何领域都不足以当主治"的成员，这个模式就失效了。课程随机分组可能出现这种情况，目前还没找到好方案。
三、新产生的问题
问题一：AI辅助编程的边界在哪里？
结对和团队项目中大量使用AI生成代码、测试用例。但如果AI写了大部分代码，开发者对代码的理解深度会不会下降？这还算"做中学习"吗？而且AI辅助让"写代码"时间缩短了，但"审查AI代码"的时间成了新的不确定性，会不会让工期预估更难？
问题二：文档与敏捷如何平衡？
团队项目中先写规格说明书再编码，但需求经常在编码阶段才明确，文档反复修改很痛苦。完全不做文档，后期维护又麻烦。有没有轻量级的文档策略，既能保留关键决策记录，又不成为负担？
四、六个阶段，每个阶段学到的一个知识点
需求阶段 — 消除二义性
campus项目中"智能推荐学习计划"有歧义：是推荐时间还是推荐内容？编码阶段才暴露，导致返工。需求文档的核心价值不是描述功能，而是消除歧义。
设计阶段 — 接口契约
T1的辅助函数（calculateScore等）为T2/T3奠定基础；campus后端用schemas/定义数据接口，前后端并行开发。设计阶段最重要的产出是模块间的接口契约。
实现阶段 — 重构时机
T3从if-else硬编码迭代到价值权重版本。重构的最佳时机是测试全部通过之后、添加新功能之前，这样不会引入回归Bug。
测试阶段 — 测试重点
T1设计了8个关键测试场景覆盖判定分支。测试的价值不在于覆盖率数字，而在于是否覆盖了"容易出错的地方"。
发布阶段 — 环境一致性
结对项目中Node.js和AssemblyScript版本不一致导致编译错误；campus用requirements.txt、package.json统一环境。"在我电脑上能跑"是最危险的一句话，发布要确保环境一致。
维护阶段 — 日志记录决策
T3调试时只能看到输赢结果，加了决策日志（手牌、评分、选择）后效率大幅提升。好的日志不是记录"发生了什么"，而是记录"为什么这样决定"。
五、个人项目 / 结对编程 / 团队项目的心得
个人项目
一个人写代码容易陷入"能跑就行"的心态，没有code review和测试约束。这让我意识到PSP、TDD等方法论的价值——它们是在弥补个人自律的不足。
结对编程
结对的价值随任务复杂度递增：
- T1（简单）：两人一起做反而拖沓；
- T2（中等）："驾驶员+导航员"模式发挥作用，一个人写代码时另一个人能保持全局视角；
- T3（复杂）：结对成了必需品，AI策略设计需要不断讨论推翻，一个人兼顾不来。
结论：结对适合"有一定复杂度、需要持续讨论"的任务，简单任务单人开发+code review更高效。
团队项目
campus项目让我经历了完整的软件工程流程，最深的体会：
- 沟通成本远超预期：六个人统一"AI聊天触发方式"就讨论了两次会议。后来学会用文档沉淀方案再决策，效率提升很多。
- 技术选型要为团队服务：选FastAPI+Vue3是因为团队熟悉Python和TypeScript。如果选了"更好"但没人会的技术栈，进度会大受影响。
- "足够好"比"完美"更重要：限流方案从令牌桶简化为固定窗口计数器，因为后者已满足需求，这个决定让我们按时完成Alpha发布。
总结
这学期最大的收获：软件工程不是关于代码的技术，而是关于"人如何协作构建软件"的技术。PSP、结对编程、团队分工，核心都是"人"。这些知识点不是背概念背出来的，而是通过花见小路和campus两个项目"做中学习"内化的。
浙公网安备 33010602011771号