软工 [I.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	首页 - 2026年春季软件工程 - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	系统掌握现代软件工程的核心概念与常用方法（需求分析、团队协作、开发流程、测试与发布等），并能通过阅读、提问与实践，在课程项目中运用这些方法，提升工程化思维与协作能力。
这个作业在哪个具体方面帮助我实现目标	通过阅读教材/讲义并提出至少五个问题，训练批判性阅读与提问能力，加深对现代软件工程概念的理解

---

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

讲义现代软件工程讲义 2 开发技术 - 单元测试 & 回归测试 - SoftwareTeacher - 博客园中写道：“单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。” 并提到：“如果忙到连单元测试都没有时间做，那么你也没有时间写好这个功能。”

我认同“作者最了解实现细节”这一点，但在先前OO等课程作业中，我的测试经验是：作者也最容易陷入“按自己的理解去测”，漏掉边界和异常路径等难以发现的错误，OO作业的互测环节也体现了这一点。另外，目前AI的代码能力迅速发展，使用AI自动生成测试骨架/建议用例会比手搓测试用例效率更高。在实际的实践中常见“测试左移”，由测试/QA 参与设计用例、编写部分单元测试，以弥补开发侧测试不足。

因此我认为，为了进行更完备的测试，或许让一个不了解代码实现细节的人进行单元测试的编写，测试效果会更好（但是这个人需要了解该程序的具体使用场景和功能特性，模拟用户的使用进行测试）

---

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

技能的反面 - 魔方 - SoftwareTeacher - 博客园中提出，提高技能需要“通过不断的练习, 把那些低层次的问题都解决了, 变成不用经过大脑的自动操作, 然后才有时间和脑力来解决较高层次的问题。”

然而，在当下的编程实践中，AI工具已经能高效地接管大量简单任务：语法查询、样板代码生成、基础调试辅助等，开发者通过使用AI，能直接站到更高的起点，通过准确的prompt，AI可以迅速完成代码的编写。但这并不意味着能力要求变低了，开发者的核心能力从“编写代码”更多地转向“指挥、审查与评判”。在运用工具时，如何使用工具能够使效率最大化是一个关键的问题。另外，在使用AI辅助编写代码时，如果没有经过理解与审核代码的过程就全盘接受，后续出现bug的话将会加倍痛苦。

因此，我认为目前开发者的能力需求从单纯地编写代码转向了理解、分析与解构问题，并能有效驾驭AI工具的“架构师”，代码的部分其实并不是那么关键了。

---

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

现代软件工程讲义 3 结对编程和两人合作 - SoftwareTeacher - 博客园中描述了结对编程的角色分工（驾驶员与领航员）、适用场景以及避免的误区等。然而，高效结对编程不仅仅在于遵循这些规则，更在于双方能否建立真正的协作默契。许多初次尝试的搭档往往停留在“一个人写、一个人看”的表面形式，未能进入深度协作状态。

在AI辅助编程工具日益普及的今天，许多编码任务可以被AI自动完成。这是否会削弱结对编程的价值？或者说，AI能否成为结对编程中的“第三位成员”，承担部分领航员的职责——例如实时审查代码、提醒常见错误、提供重构建议？如果AI可以替代部分技术性复审工作，那么人与人结对编程的核心价值是否应该转向更高层次的协作——如问题拆解、架构设计、业务理解？

当AI承担了更多“低级”工作后，驾驶员与领航员的角色是否需要重新定义？两人结对时，是否应该更多地用于讨论“为什么要这样做”而非“怎样写这段代码”？在AI时代，结对编程的实践方式可能发生怎样的演变？

---

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

敏捷开发原则 - SoftwareTeacher - 博客园中，第二条是“敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势”。同时，敏捷又通过Sprint（冲刺）、Sprint Backlog（冲刺待办列表）和每日立会来建立短期的、可执行的计划。书中也提到了Sprint是时间驱动的（Time-boxed），时间一到就结束。

我的疑问是，在一个Sprint进行到一半时，如果产品负责人（Product Owner）或一个关键用户提出了一个极具价值但不在当前Sprint计划中的紧急需求，团队应该怎么办？

现代软件工程讲义4 Scrum/Sprint - SoftwareTeacher - 博客园中提到了一个非常生动的例子：“冲刺到一半的时候，产品负责人突然发现要马上做重要的改动！……如果一个运动员在跑一百米冲刺，但是跑到一半的时候，领导突然想看一百一十米栏的比赛，前面马上会摆起栏架……” 这个例子精准地描述了这种困境。书中给出的建议是“要改主意，也要等到老子冲刺完了再说啊！”

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

---

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

现代软件工程课件 需求分析 如何提出靠谱的项目建议 NABCD - SoftwareTeacher - 博客园中强调要“充分了解用户的痛苦”，同时指出：“用户往往也不知道颠覆型的创新”，并举例——若福特当年只问用户要什么，用户会说“更快的马车”。需求要分析是刚性还是辅助、量有多大、是否会持续存在，并建议找到至少 10 个表示“一定会试用”的潜在用户。

讲义中对“如何从访谈/问卷中提炼出可验证的真实需求”的方法论写得相对概括。用户常常说不清痛点，或把“想要”说成“需要”，需要再从其中提取核心的需求。另外，不同用户提出大量的各种不同的需求，我们需要对这些需求进行优先级排序，以先实现那些真正重要的、核心的需求。

这个问题可能和上一个问题有些类似：要如何区分“真实需求”与“口头表达的需求”，并对需求的重要程度进行排序？是否有一个可以量化重要性与可实行性的方法来实现这一点？