[I.3] 个人作业：结课总结

1. 链接到以前提问题的博客

https://www.cnblogs.com/kkkara/p/19702938

2. 曾经的困惑与现在的解答

Q1：软件工程师的思维误区如何度量？（分析麻痹等）

解答： 实践中我发现，度量的标准主要体现在交付的速度与反馈。
在团队项目 Alpha 阶段，我们曾花大量时间争论架构细节，导致前几天几乎啥都没干产出极低。后来我们采用 Scrum 的看板管理，强制要求任务颗粒度拆分到“半天内可完成”。当我发现一个任务在看板上停滞超过 2 天，就说明我陷入了思维误区。通过燃尽图（Burn-down Chart），我直观地看到了犹豫带来的进度滞后。

Q2：结对编程如今还有必要吗？（对比 AI 编程）

解答： 有必要，但形式在演变。AI无法完全替代真人伙伴。
如何弄清楚的： 在结对项目中，我和搭档尝试了“人-人结对”和“人-AI结对”。我发现 AI 虽然能快速写出代码，但在复杂逻辑下会产生“幻觉”，而人类伙伴能在我逻辑滑坡时及时提醒。结对编程的核心在于“实时 Code Review”和知识传递，这是目前的 AI 辅助编程（Vibe coding）难以完全覆盖的深度交互。

Q3：PM 的设置是否必要？

解答：太有必要了
如何弄清楚的： 在团队项目中，由于最初 PM 职责不明确，前后端联调时由于接口文档不一致导致了大量重工。后来 PM 站出来协调规格书，并主动对接需求变更，开发人员才得以专注。我意识到 PM 的“虚”是为了让开发的“实”更有方向，没有 PM，团队会陷入无序的。

Q4：测试的角色需要独立出来吗？

解答： 都可以，但测试环节必须独立。
如何弄清楚的： 我起初认为开发者自己测就行。但在 Beta 阶段，我修复的一个“简单 Bug”导致了登录功能的全局崩溃。这让我意识到：开发者由于思维定势，很难发现自己的逻辑盲区。虽然课程中我们没有专门的测试员，但我们通过交叉测试模拟了“独立测试”的效果，这比自测有效得多。

Q5：“小作坊”模式在 AI 时代是否能改善？

解答： AI 降低了“作坊”的准入门槛，但内功决定了作坊能开多久。
如何弄清楚的： 通过本学期的实践，我发现 AI 能帮我写MVP，但在后续代码交接和系统维护时，如果没有良好的规范、文档和架构，AI 生成的代码会变成沉重的债务。修炼内功是为了在 AI 的加持下跑得更稳，而不是为了不被 AI 替代。

3. 依然存在的困惑与新产生的问题

3.1 尚未完全明白的问题

遗留问题： 在高度动态的软件开发中，“过早优化”和“架构前瞻性”的界限究竟在哪里？ 我依然很难判断，当前的某个解耦设计是为了未来的灵活性，还是在做无用的功。

3.2 产生的新问题

新问题： 我发现即便有文档，理解前人的代码意图依然非常痛苦。在 AI 时代，是否有更标准化的方式（如代码图谱化）来降低这种“接盘”成本？

4. 软件工程六阶段的知识点总结（做中学）

需求阶段：用户故事与优先级排序。
学习了使用 Backlog 管理需求，明白不能什么都做，要通过“重要性-紧急度”矩阵确定 Alpha 阶段的核心功能。
设计阶段：API 优先原则。
在前后端分离开发中，先定义 Swagger 接口文档，比直接写代码重要得多，这解决了协作冲突。
实现阶段：Git 工作流。
通过团队协作，我真正掌握了 feature-branch 模式和解决冲突（Merge Conflict）的实操经验。
测试阶段：回归测试。
学会了每次合入新功能后，必须跑一遍主流程，确保旧功能没有被“改坏”。
发布阶段：自动化部署。
学习了如何配置简单的 CI/CD 流水线，让代码合入主干后自动部署到测试环境。
维护阶段：异常堆栈跟踪与日志分析。
学会了不再盲目本地调试，而是通过服务器日志（Log）定位线上生产环境的问题。

5. 个人/结对/团队项目的心得体会

1.团队合作是一门很重要、很深的学问，这个东西远远没有想象中简单
2.代码质量是后续一切的基础。
3. 深刻理解了《构建之法》中提到的“团队协作不是简单的加法”。
总结感悟： 软件工程不是关于“写代码”的学问，而是关于如何在有限的时间、人力和资源约束下，交付有质量的可靠产品。实践是检验真理的唯一标准，而这一学期的代码行数和提交记录，就是我成长的最好见证。