北航 2026 软件工程课程《结课总结》作业

北航 2026 软件工程课程《结课总结》作业

项目	内容
这个作业属于哪个课程	2026年春季软件工程(北京航空航天大学-计算机学院)
这个作业的要求	I.3 个人作业：结课总结 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	学习系统的软件开发过程，完成一个简易项目的开发
这个作业在哪个具体方面帮助我实现目标	回顾软件工程理论和基于理论开发的实践，给出方法论更新后的反思

回到最初的问题

根据课程要求，这是我最初提出问题的链接：北航 2026 软件工程课程《阅读和提问》作业 - lazyfish-lc - 博客园

现在，让我们回顾一下这些问题：

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

根据实践结果来看，当然不必须。实际上，在完全约定好接口行为之后，我和负责测试的同学就处在一个几乎并行协作的状态，并且该同学的测试也确实起到了相当多的纠错效果（我的功能实现的一个差错就是由此检测出来的）。

然而如果所有测试都进行分层，也就意味着程序的作者有可能无法 review 功能的合法性，有可能会使得错误发现的更晚（即便是根据规章制度进行机械的编写，总归是可以检查各分支的正确性），若进行推送后再发现 bug 并修改，可能会引发更混乱的修复过程，得不偿失。

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

对于跑神和精力消耗的问题，实际上问题往往在于“领航员不知道另一方具体在做什么”。在结对编程任务时，我和队友常常处于“我不知道对方在干什么”和“我不需要知道对方在干什么”的状态，因此一个解决办法就是“对方主动说出需要让我（领航员）知道的内容”和“准备下一步动作和及时轮换”。

以及，在之前提出问题的时候，我举了个 ICPC 的例子来佐证问题的存在，然而现在发现这个比方实际上是有问题的：赛场环境精力消耗的主要因素在于复杂的算法核验，这在实际项目中往往不会拖到实现阶段才被解决。

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

和单元测试的问题提到的类似，同样是在项目实施的过程中，我们发现其实只要有了一个差不多的接口约定，并行协作就是有可能的。在设计的时候就对测试参与讨论，并且并行的编写测试用例，能够让测试质量得到保证。

当然实际上还有一个尚未解决的问题就是，测试规模应该如何制定。（初步的想法是尽可能保证单元和模块测试的稳定性）

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

在现在，不成为领域的专家还能更容易创新，但是未来能做的事情会越来越少，或者对人的洞察力需求会越来越高。

在 AI 时代，人们获取信息的速度变得非常快，实现想法的速度也会变得非常快。我们团队的游戏开发就是这样，实际上在课程开始前，没人真的对游戏开发有过系统性的了解，甚至可以说没人有像样的经验。然而这个状态在开工后的不久就发生了变化，从有想法，学会实现方案，到交给 Agent 编写代码，全程用不了多长时间。

然而这也意味着换一个非计算机专业的学生，花的时间长一点，也可以做到这些的一部分。区别在于，现在的 Agent 还没法完全理解如何规范的开发软件，人类就总是可以在架构上进行一些指导。

不过这种场景在未来很可能也会消失，至少我们都不用在触碰最后一层实现了。这个时候，开发能力是要给领域专业知识让路的。

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

其实界限还挺模糊，但是也确实存在一个例子。

在开发的 Alpha 轮，我为了当时讨论出的功能设计了一个比较复杂的架构。有点复杂，但是可以保证即使更换了目标，也不至于伤筋动骨的调整。但是实际上，这个架构也有相当一部分并没有为开发带来多少便利，最后大家实现的功能还是那么多，甚至这个架构的一部分只用了寥寥数次。

感觉上来说，对于过早扩大化，关键还是需要先验证一个想法可行，再验证这个想法能给用户带来便利/舒适，最后才是把这个想法融合进已有的大框架里，而不是一开始就假设这个框架里有这个功能。

至于性能优化的问题，这实际上不应该和远景矛盾。类似二八定律的东西也可以用在性能上，往往我们只需让里面的一小部分的步骤“不那么符合规范”，保证整体架构松快一些。

然而有了一个很大的新问题

AI 会有一天能够理解和实践软件工程的各个内容吗？在可以/不可以的时候，我们应该做些什么？

这可能有点超出软件工程课程探讨的范围，但是这个问题确实是开发的时候自然形成的一个疑问。

我们的团队项目是高度依赖 AI 编码的，仅在不得不通过 Unity 编辑器操作，或者绘图的时候才会动手（画地图，填充data之类的（甚至这个有时候也可以用 AI，反正是 yaml 类似物））。在我上其他课程/听同级助教聊下一级完成其他课程内容的时候，也经常听到一个抱怨：“AI 摧毁了一个领域基础学习的步骤”（总之差不多是这么个意思）。

对于大部分课程，我的看法实际上是乐观的：不论是计组，操作系统，还是编译技术等等，这些工作的含金量本来就不在高效组织开发上，AI 的发展反而有利于课程的减负（以及更深刻内容的推出）。

然而对于面向对象，软件工程一类的课程，其重点之一在于设计、编码和测试始终能够支持版本迭代，而这一点在 Agent 越发有用的现在在被逐渐削弱。对软件工程来说，问题似乎压到了实现之外的部分，比如需求分析，进度规划，用户反馈等等，至于从设计到部署的过程，似乎本专业的学生在其中的工作量被消减的越来越厉害。

那么，我们未来应该更关注哪些环节，做出哪些改变呢？或者说，和软件开发相关的专业知识是否变得逐渐不重要，以至于从事软件开发不应该是本专业的关注目标？

实践中的知识点

阶段	知识点	工程体现
需求	描述用户的需求时，需要具体到可验证的行为	在最开始提出游戏基本规则时，使用的描述较为模糊，导致后续进行设计时需要频繁回顾和细化需求
设计	需要交付完整的接口契约	发现对于任务重叠的部分，确认契约再开发后，并行程度能够得以提升
实现	先用可行代码跑通流程，再考虑重构/优化	想在实现初期就做出完美架构，结果一定程度上陷入了过度设计
测试	需要注意测试用例本身的错误	设计的部分用例属于测试人员理解错误引起的测试bug，但debug时未想到这一点
发布	需要注意开发和发布时的环境不同带来的运行差异	产品发布前游玩时发现部分由于环境不同引起的bug
维护	修复bug时注意回归测试	同知识点所属，差点出现了改完bug之后，回归测试不通过的情况下仍合并至develop的情况

心得

现在的 AI 距离理解软件工程还是差了很多。

在整个团队高强度用 AI 做完开发之后，我最大的感受是：AI 确实极大缩短了“从想法到可运行代码”的距离，但它并没有真正替代软件工程中那些需要判断和决策的环节。

具体来说，AI 能很熟练地生成 Unity 脚本、实现接口、写出基本的测试框架，但前提是得先想清楚“要做什么”和“怎么做才算对”。需求细化、接口约定、模块划分、测试策略……光是这些，靠的是就是人对项目的理解，如果人的理解不好，AI 生成的代码反而容易掩盖设计上的缺陷，从而付出更多的修改成本。

回想起来最常用的 Agent 的实现，突然有了一种松了一口气的感觉：我们还没有教会 AI 干这些，也没有很好的描述分析和开发的流程。有些经验性的东西仍然需要人在其中做判断，只是……也不是很需要那么多人。

所以回到之前那个大问题——软件工程专业的核心仍然是那些，但侧重点应该不完全在手动实践了。实现层面的技能会越来越容易被替代，而需求分析、系统设计、过程管理、以及对复杂问题的拆解能力，才是未来更值得投入的方向。这门课让我完整经历了一次开发周期，也让我看清了在哪些环节必须靠自己的判断力。这可能比单纯学会某种技术更有价值。