[l.1] 个人作业：阅读与提问

[l.1] 个人作业：阅读与提问

项目	内容
这个作业属于哪个课程	2026年春季软件工程 - 北京航空航天大学 - 班级博客
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问 - 作业 - 2026年春季软件工程 - 班级博客 - 博客园
我在这个课程的目标是	学习软件工程相关基础知识
这个作业在哪个具体方面帮助我实现目标	了解软件工程的基础知识，大致理解本课程需要学习的内容范围，提出一些问题供之后学习过程解答。

问题一：当代码由AI生成而非手写时，书中的“单元测试由作者负责”是否依然成立？

章节： 第2章《个人技术和流程》2.1.2 好的单元测试的标准
引用：

“单元测试必须由最熟悉代码的人（程序的作者）来写。代码的作者最了解代码的目的、特点和实现的局限性。”

提问：
书中强调单元测试应由代码作者负责，因为作者最了解代码的逻辑和边界。但随着GitHub Copilot、Cursor等AI编程助手的普及，大量代码由AI生成，开发者往往只做审查和微调。在这种情况下，谁是“代码的作者”？如果开发者对AI生成代码的底层逻辑理解有限，他们还能写出有效的单元测试吗？单元测试的责任是否应该从“代码作者”转移到“AI工具”或“测试自动化框架”？

支持资料：

• 近期讨论指出，AI生成代码具有“非确定性输出”特性，同一需求可能生成完全不同的实现，给单元测试带来新挑战。
• 有观点认为，当代码由AI生成时，测试驱动开发和自动化验证机制比以往更加重要。

个人经验：
我在使用AI辅助编程时，经常发现自己对AI生成的代码逻辑只有模糊的理解，尤其是当AI采用了非直观的实现方式时。这种情况下，我很难写出针对边界条件的全面测试。

困惑：
在AI辅助开发成为常态的今天，书中的“作者负责测试”原则是否需要重构？我们是否需要新的测试方法论，专门针对AI生成代码的特性？测试的责任应该如何重新划分？

---

问题二：软件开发流程的演进方向是从“个人流程”到“平台工程”，这与书中反复强调的“个人能力”是否矛盾？

章节： 第2章《个人技术和流程》2.3 个人开发流程（PSP）
引用：

PSP要求工程师记录每个阶段的时间、缺陷、代码行数等数据，并进行事后总结和改进。

提问：
书中详细介绍了PSP即个人软件流程，强调工程师个人通过数据收集和流程改进提升能力。然而，近两年软件工程领域兴起的“平台工程”理念，核心思路是通过构建内部开发者平台来屏蔽底层复杂性，为开发者提供便利，从而减少个人需要的工具链使用要求。这种“平台代替个人承载复杂性”的思路，与PSP强调的“个人精确控制流程”形成对比。在平台工程时代，个人还需要像PSP要求的那样精细记录和分析自己的行为吗？

支持资料：

• 平台工程的出现是为了解决实践中开发者被过多工具和任务所限制而无法研究更加重要的方面的问题，让团队专注于构建软件而非管理工具和管道。
• 大量的现代公司或者组织依赖内部开发者平台来标准化工具链。

个人经验：
我在使用一些成熟的代码开发平台时，很多基础设施层面的问题都被平台接管，个人确实不需要像PSP要求的那样关注每一个细节。

困惑：
在平台工程成为主流的组织中，PSP的价值如何体现？个人流程的精细化与平台提供的标准化之间应该如何平衡？

---

问题三：当“无代码/低代码+AI”让业务人员成为开发者时，书中的“软件工程师成长路径”是否需要重新定义？

章节： 第3章《软件工程师的成长》3.3 软件工程师的职业发展
引用：

书中描述了软件工程师从“临时寄托”到“工作”到“职业”到“事业”到“理想呼唤”的成长阶梯。

提问：
书中对软件工程师的成长路径描述，建立在“写代码是核心技能”的前提上。但通过近年的一些ai的发展可以看出，之后大量的新应用将由非专业开发者通过无代码/低代码平台创建。这些人并不懂传统的编程语言、数据结构或者算法，却能通过AI辅助快速构建可用的业务系统。在这种情况下，传统软件工程师的“核心竞争力”是什么？书中的成长阶梯是否还能适用？

支持资料：

• 无代码平台结合AI后，用户可通过自然语言描述直接生成应用，开发门槛大幅降低。
• 有观点认为，软件工程正在进入“软件工程3.0”时代，人机交互智能成为常态，数据和模型价值愈发凸显。

个人经验：
我观察到，一些业务人员现在确实可以通过无代码平台独立搭建出曾经需要IT部门数月才能完成的应用。这让我思考：当开发工具越来越智能，软件工程师的不可替代性到底在哪里？

困惑：
未来软件工程师的核心能力是否会从“代码编写”转向“复杂系统设计”“AI协作管理”或“领域知识建模”？书中的成长阶梯是否需要加入这些新维度？如果公民开发者能够解决大部分简单业务需求，软件工程师应该向哪个方向进化？

---

问题四：书中提倡使用 goto 实现函数单一出口，这与现代编程规范中“避免使用 goto”是否矛盾？

章节： 第4章《两人合作》4.3.2
引用：

函数最好有单一的出口，为了达到这一目的，可以使用 goto。只要有助于程序逻辑的清晰体现，什么方法都可以使用，包括 goto，如代码清单4-2所示。

提问：
书中明确建议使用 goto 来实现函数的单一出口，并给出了错误处理中跳转到统一清理代码的示例。然而，自 Dijkstra 1968 年发表《Go To Statement Considered Harmful》以来，许多编程教材和公司编码规范都强烈建议避免使用 goto，认为它破坏程序结构、导致“意大利面条式代码”。在 C++、Java、C# 等现代语言中，异常处理、智能指针等机制已经能更安全地处理资源清理和错误路径。那么，在2020年代的软件开发中，goto 是否仍应被视为一种可接受的实践？单一出口原则是否必须通过 goto 实现？有没有更好的替代方案？

支持资料：

• Dijkstra: “Go To Statement Considered Harmful”.
• Linux 内核编码规范中允许 goto 用于错误处理，但仅限于此场景。
• 许多公司编码规范禁止 goto，除非在生成的代码中。

个人经验：
我在学习 C 语言时，老师强调避免 goto，但后来阅读 Linux 内核代码时发现大量 goto 用于错误处理，这让我困惑。在编写 C++ 时，我倾向于使用析构函数自动释放资源，但 C 语言没有这种机制，goto 似乎是一个简洁的解决方案。

困惑：
书中建议“只要有助于程序逻辑的清晰体现，什么方法都可以使用”。但在团队协作中，goto 的使用是否会导致代码可读性下降？是否应该根据语言特性来决定是否使用 goto？如果使用 goto，有哪些最佳实践（例如只向前跳转、避免跳入循环等）？

---

问题五：如果AI能让“重写”比“维护”更便宜，书中强调的“可维护性”原则是否还成立？

章节： 第3章《软件工程师的成长》3.1 个人能力的衡量与发展
引用：

书中提到软件的可维护性是衡量工程师工作质量的重要标准，“交付的代码中有多少缺陷”和“代码从开始写到发布一共修改了多少行/次”都是衡量指标。

提问：
书中强调可维护性，认为好的代码应该易于理解和修改，降低长期维护成本。但有人提出，在AI可以根据需求快速重新生成整个系统时，“维护”这个概念可能需要重新思考：如果修改需求比修改代码更重要，我们是否应该版本控制的是“意图”而不是“实现”？当AI能够在一小时内重写整个模块时，投入大量精力去“维护”现有代码是否还有必要？

支持资料：

• 有观点认为，在AI时代，传统diff工具记录的代码变化可能不再是核心，更值得记录的是“开发者意图的变化”。
• 如果重写的成本低于维护成本，那么软件工程的“可维护性”优先原则可能面临挑战。

个人经验：
我确实遇到过这样的情况：面对一个结构混乱的旧代码，我花了两天时间试图理解并修改它，后来发现让AI重写一遍只花了两个小时，而且新代码更清晰。

困惑：
“可维护性”和“可重写性”之间是否存在一个成本平衡点？当AI的代码生成能力足够强大时，软件工程的重心是否会从“维护现有代码”转向“快速重构和替换”？如果是这样，工程师的评估标准是否需要从“代码质量”转向“需求转化效率”和“系统整合能力”？

---

以上问题反映了我在阅读《构建之法》时，结合近两年软件工程领域新趋势（AI辅助开发、平台工程、无代码/低代码、角色演变）所产生的思考。书中许多原则建立在传统开发模式的基础上，而技术发展正在改变这些前提假设。期待与老师和同学探讨这些话题。