北航 2026 软件工程课程《阅读和提问》作业

北航 2026 软件工程课程《阅读和提问》作业

项目	内容
这个作业属于哪个课程	2026年春季软件工程(北京航空航天大学-计算机学院)
这个作业的要求在哪里	I.1 个人作业：阅读和提问 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	学习系统的软件开发过程，完成一个简易项目的开发
这个作业在哪个具体方面帮助我实现目标	快速理解软件开发的范式与实践方法，激发阅读和反思

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

在第2章“个人技术和流程”，关于“好的单元测试的标准”的讨论中，提到如下标准：

“单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。”

“如果忙到连单元测试都没有时间写，那么你也没有时间写好这个功能。在一些极限编程的方法中，是可以考虑让别人来做单元测试的，但是，程序的作者还是要对单元测试负责。”

最好是在设计的时候就写好单元测试，这样单元测试就能体现API的语义，如果没有单元测试，语义的准确性就不能得到保障，以后会产生歧义。

作者在此处强调单元测试需要体现 API 的语义，不仅是对规格正确性的验证，也是对规格要求的体现。然而，支撑该论点的种种论证都在强调“对规格要求的体现”，而忽视了其作为测试的基础要求。

此外，作为一个工程项目，如果将实现的责任和测试的责任放在同一个人身上，那么由于个人的过分自信/时间紧张等因素，其测试不完善的可能性会被放大，也并不如专业的测试人员进行编写覆盖更加全面。尽管除单元测试外仍然存在更多的测试手段，但此种安排相较于实现测试分离的思路而言，缺乏对测试有效性的保障？

结对编程中，“领航员”角色是否真的能始终保持高效，而不流于形式？

在第4章“两人合作”，关于“结对编程”的讨论中，提到如下内容：

“在结对编程模式下，一对程序员肩并肩、平等地、互补地进行开发工作……其中有‘驾驶员’（Driver）和‘领航员’（Navigator）两个角色……能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。”

这里假设了“领航员”能够持续地、专注地进行高层次思考（设计、测试用例、未来重构），并且“驾驶员”和“领航员”的角色可以平等、顺畅地互换。这要求两人都有极高的自律性、沟通技巧和相同的思维节奏。

在与之类似的 ICPC 赛场的后期，也有类似结对编程风格的竞赛策略，然而实践经验发现，由于其对“领航员”的要求过高，导致即使是连续工作不超过 1 小时，也容易出现精力消耗过大的问题。

尽管考虑到赛场环境和真实开发环境的要求具有一定区别，精力消耗差异也较大，然而一人领航的做法仍然容易产生跑神/理解进度过慢的问题，因此该问题的克服是否过于理想化，有什么办法能够在模式上进行一定的调整？

在敏捷流程中，测试人员如何在“冲刺”的时间压力下，真正担当起“质量守门员”的角色？

在第6章“敏捷流程”，关于敏捷流程的第三步（冲刺）的讨论中，提到了测试人员的角色困境：

“软件团队中还有一个重要的角色——测试。测试人员在一个冲刺中怎么工作呢？有敏捷专家建议测试人员可以担负起产品负责人（Product Owner）的部分责任，同时掌握验收测试流程，对产品的最终质量负责。但是测试人员的开发技术能力在团队中并不占优，他们在大家都要‘烧光’所有任务的压力下，能担当起产品负责人这一责任么？”

“Sprint结束后，各个任务宣告完成，并且没有P1（最严重的）Bug，但是P2及以下的Bug有80多个”。

这直接说明，即使在规范的敏捷流程中，“冲刺完成”也不等于“高质量完成”，大量后续工作（即书中所谓的“第三步半”）被遗留了下来。那么，如果测试人员被要求对质量负责，但在冲刺计划中却没有足够的时间来执行完整的测试（包括探索性测试、回归测试、效能测试），那么如何才能负责呢？是否存在这样一种做法，使得在敏捷流程中能够让测试穿插于质量保障中呢？

在软件领域发展复杂，且由其他计算机分支带动发展的今天，不成为领域的专家是否会失去创新的基础？

在第16章IT行业的创新，关于创新的迷思里，提到了对“要成为领域的专家，才能创新”的反例举例：

但是统计数据表明,70%的创新者说,他们最成功的创新,是在他们的拿手领域之外发现的。

蒂姆·伯纳斯-李是一个物理学家,他在1989年3月提议,想利用超文本(HyperText)实现方便的信息共享和更新。他的老板看了之后,说“Vague,but exciting.”一年后,他和同事们实现了通过互联网的HTTP协议通信,WWW就这样诞生了。

这个现在看起来这么顺理成章的想法,为什么是由一个物理学家,而不是计算机学家实现出来的?事实上在WWW/HyperText协议刚出现时,一些计算机专家非常看不起这个玩意(根据我看到的2001年资料),专家们认为,一个文本文件上有一些文字,有些是蓝色的,用鼠标一点,就能打开另一个文件,网页上都不记录状态,这算什么难度,这又是什么创新呢?这能在什么地方发表论文呢?当时计算机科学家在搞COM、DCOM、远程过程调用(Remote ProcedureCall,RPC)这样一些高难度的东西。

事实上,正是这种看似简单的无状态(Stateless)的网页,改变了世界。

然而，当今软件领域已变得异常复杂，前沿创新往往需要深入的专业知识（例如人工智能、分布式系统、编译器设计等）。在这样的背景下，如果不成为某一领域的专家，是否还能做出有影响力的创新？或者说，跨领域的思维是否仍然是创新的重要来源？书中这个例子在今天是否依然具有普遍性？对于学习软件工程的学生而言，我们应如何在“深耕专业”和“拓宽视野”之间取得平衡，以更好地激发创新潜力？

软件工程师的思维误区“过早优化”和“过早扩大化”，是否与“为共同的远景而工作”存在矛盾？

在第3章中提到了过早优化和过早扩大化的思维误区：

一个工程师在写程序的时候，经常容易在某一个局部问题上陷进去，花大量时间对其进行优化...

有的程序员往往灵光闪现——哎，能不能把类型抽象出来，让这个函数处理所有可能的类型？这样不就一劳永逸了么？

但在第7章中又提到了为共同的远景而工作的原则：

“为共同的远景而工作”...这个目标必须是明确的，没有二义性；...不是当前就能达到，必须是通过努力才能达到的；...不是空泛的，它应该对项目成员每天的工作都有指导作用。

然而，一个强烈的、长远的共同远景，其本身就蕴含着“扩大化”和追求“卓越”（优化）的基因。那么，在实践中，工程师该如何区分“为实现远景而进行的有远见的设计探索”和“导致项目失败的过早扩大化”？如何判断对某个模块的深度打磨是“必要的性能投资”还是“脱离全局的过早优化”？这两者之间的界限非常模糊。