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

项目	内容
这个作业属于哪个课程	首页 - 2026年春季软件工程 - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[I.3] 个人作业：结课总结 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	系统掌握现代软件工程的核心概念与常用方法，并通过阅读、结对编程与团队项目实践，提升工程化思维与协作能力
这个作业在哪个具体方面帮助我实现目标	回顾学期初的提问，对照一学期的实践经历进行反思与总结，检验“做中学”的收获

---

一、链接到学期初的提问博客

学期初完成的阅读与提问作业：

[I.1] 个人作业：阅读和提问 - REROSAMA - 博客园

---

二、对学期初五个问题的回顾与解答

Q1. 单元测试是否“必须由最熟悉代码的人（程序作者）来写”？

学期初的困惑： 讲义中明确写道：“单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。”还提到：“如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。”

因此我当时认为，为了进行更完备的测试，或许让一个不完全了解代码实现细节、但熟悉程序具体使用场景和功能特性的人来编写单元测试，模拟用户的使用路径进行测试，效果会更好。

现在的理解： 经过一学期的实践，我认为作者写单元测试仍然是合理的默认选择，因为作者最清楚模块的输入输出契约、隐含前提和实现局限。结对项目第一次任务中，我们在花见小路判定模块里按“立即胜利优先于轮次，轮次优先于第三小轮细分”的优先级编写判定逻辑，并为每个返回值分别设计测试用例，这种对分支顺序的覆盖，离不开对规则和代码结构的同步掌握。

不过，“作者写”并不等于“作者独自写”。第一次结对任务中，遵循顺序约束并重视分支覆盖的测试能显著降低漏判风险；而团队项目测试阶段，随着项目规模增加，即便有单元测试和持续集成，集成场景、权限边界等仍可能出问题，这些场景往往更需要不熟悉该模块实现细节的同事从用户使用路径出发进行探索性测试。

现在我的结论是：作者负责编写和维护单元测试，团队则通过代码评审、结对复审和持续集成回归来补充盲区；人工智能可以生成测试骨架和推荐用例，但断言的合理性与覆盖范围仍然需要人来把关。

---

Q2. AI 时代中，开发者的代码能力要求是否已经发生了变化？

学期初的困惑： 开发者的能力需求正在从单纯编写代码转向理解、分析与解构问题，成为能有效驾驭人工智能工具的“架构师”，代码编写本身其实不再是那么关键的部分。

现在的理解： 能力重心确实在转移，但并非代码不再重要，而是对需求的理解、对代码功能架构的分析更加重要。结对项目最后一个任务中，我们用辅助工具生成了出牌策略的实现，编码本身变快了，但代码复审和修正所花的时间反而超过了前两次结对任务——策略逻辑、隐藏信息处理和合法动作约束如果没有逐段理解，对局时就会出现隐蔽的缺陷。

在团队项目里，人工智能更多用于整理文档、起草接口、排查配置等辅助工作，核心的架构设计（小程序、后端、管理门户和智能体）、接口契约以及发布流程仍然由团队讨论决定。开发者更像一个能够拆解问题、设计边界、判断人工智能产出是否可信的工程角色，而不只单纯写代码。

---

Q3. 如何高效进行结对编程？在 AI 时代中，结对编程是否还适用？

学期初的困惑：当人工智能承担了更多“低级”工作后，驾驶员与领航员的角色是否需要重新定义？两人结对时，是否应该更多地用于讨论“为什么要这样做”而非“怎样写这段代码”？

现在的理解： 经过结对任务后，我觉得结对编程依然适用，但其价值重心会随着任务复杂度而变化。第一个结对任务规则判定相对简单，结对带来的收益有限，主要收获是熟悉了新的编程语言环境和游戏规则。第二次和第三次结对时，解析操作历史以及设计策略的过程里，两人分别有不同的思路和想法，综合之后得到了一个比较好的方案。第三次结对则在策略设计上花了大量时间，包括调研论坛、实际试玩、头脑风暴关于不完全信息博弈的分析，这些都是结对讨论的产物。

虽然学期初设想的“更多讨论为什么而非怎么写”在一定程度上是对的，在最后一个结对任务阶段，讨论出牌策略的时间远多于逐行写代码。但是我认为，人工智能可以承担一部分领航员职能，比如语法提示、生成样板代码、提供即时审查建议，但它替代不了两人对业务规则、优先级和取舍达成共识的过程。

---

Q4. 敏捷流程中，如何平衡“响应变化”与“遵循计划”？

学期初的困惑：现实中，尤其是竞争激烈的互联网行业，假如那个“突然的重要改动”确实是一个非常有价值、可以抢占市场的机会，严格遵守冲刺的边界是否过于僵化？我们该如何区分“有价值的市场变化”和“不是那么有价值的临时起意”？如果团队总是为了“保护计划”而拒绝变化，那“响应变化”的原则是否就没有意义？

现在的理解： 我认为讲义中的观点在大多数迭代场景中是成立的：无节制地打断冲刺会破坏可预测性和团队节奏。实践中我们也遇到过“变化”与“计划”之间的张力。beta阶段中，虽然并未遇到临时更改需求的场景，而是计划对技术不确定性预留不足，导致工作未能跟上进度。团队事后总结的改进措施是，对涉及新技术栈的复杂功能，在冲刺开始前必须完成技术预研和原型演示，把原型验收作为开发启动的前置条件，同时将联调和部署验证从冲刺中段提前，而不是堆到冲刺末尾。

对于“极具价值的紧急需求”，我的倾向是默认等到当前冲刺结束，再纳入待办列表并重新排定优先级。如果确实属于最高优先级，则使用已经预留的缓冲时间优先完成。区分“真正值得响应的变化”和“临时起意”，需要产品负责人用数据或用户证据来判断。

---

Q5. 要怎么提取出用户真正需要的需求？

学期初的困惑： 用户常常说不清痛点，或把“想要”说成“需要”，需要从中提取核心需求。另外，不同用户提出大量不同的需求，团队需要对它们进行优先级排序，先实现那些真正重要和核心的部分。要如何区分“真实需求”与“口头表达的需求”，并对需求的重要程度进行排序？是否有一个可以量化重要性与可行性的方法？

现在的理解：“更快的马车”这个例子说明，不能只看用户字面表述，而要回到使用场景和可验证的行为上。团队选题和功能规格说明做了比较完整的实践：我们定义了“时光航迹”面向新生、在校生、校友和管理员这四类典型用户，把“时空切换”“增强现实时光机”“用户贡献内容”等写成可验收的功能条目，并明确了边界，比如用户贡献内容需要审核，官方影像与用户贡献内容要区分开。这些理解来自阅读材料中关于需求分析的论述，来自团队立项和规格撰写的过程，也来自用户场景测试以及后续收到的反馈。

---

三、仍然不太明白的问题

1. 敏捷流程中“响应变化”与“遵循计划”如何取舍，在课程项目里需求变更的代价由团队自己承担，因此各需求冲突解决起来较为容易。而如果是真实工业环境下，产品负责人、业务方和技术团队各有不同考核指标，一个紧急需求对业务方是机会、对技术团队是成本，这时谁有权做决定、范围变更如何记录和沟通、隐性积压的工作又如何影响后续评估，这些问题我仍不明白。
2. 如何从用户表述中提取真实需求并排序，团队项目中我们大致是用核心功能和高级功能的粗粒度划分来解决。这个方法在项目初期够用，但随着功能清单变长、剩余时间变紧，同级别内多个需求谁先谁后就难以判断了。其他更细粒度的量化框架理论上可行，但我不清楚的是：在项目规模小、时间紧张的条件下，投入时间做一套形式化排序是否划算？以及如果不用形式化方法，又要怎么去划分优先级？

---

四、实践后产生的新问题

1. AI 辅助代码在团队中的质量责任如何划分？
   第三次结对使用生成工具实现策略后，如果线上对局出现异常，责任应该在提示词设计者、复审者还是提交者身上？团队项目中如果多人使用这类工具，代码复审应该如何进行？
2. 小团队的测试投入上限在哪里？
   第二阶段我们提升了后端单元测试规模，投入已经不低，但前端测试仍然大量依赖手工。覆盖率达到多少、哪些路径必须自动化，才能在课程周期与质量之间取得平衡？

---

五、做中学

阶段	知识点	实践
需求	用典型用户和场景把模糊想法变成可验收的功能条目	团队立项时定义了四类用户角色，为每个功能写清楚“谁在什么情况下使用、期望得到什么结果”
设计	分层与单一职责	第二次结对任务中，把“解析历史动作”和“结算当前状态”分成两层，后续规则调整时只需要改结算层，解析层不用同步更改，减少错误与修改成本
实现	可复用数据结构、渐进扩展	三次结对任务共用同一套棋盘表示和输入输出格式，直接复用数据结构
测试	分支覆盖与回归	第一次结对任务中，针对判定模块每个可能的返回值分别设计测试用例，覆盖了所有分支路径
发布	CI/CD	团队项目配置了持续集成流水线，每次合并代码后自动测试和构建
维护	Postmortem 与过程改进	每个阶段结束后进行讨论与分析，从暴露出来的问题中总结改进措施，两个阶段的项目总结中提出了预研前置、任务粒度控制、联调提前等改进措施

---

六、结合项目经历的心得

本学期的团队项目让我深刻理解了实际项目开发的场景，让我体会到工程是“人加流程加产物”的结合体。在“时光航迹”项目中，我体会了从需求分析、规格说明、敏捷例会、到持续集成部署、发布与事后回顾的完整的过程，让我感受到软件工程不仅是写代码，更是让多人可持续地交付可验证的软件。总之这一学期我学到了很多新知识，也收获了很多。