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

项目	内容
这个作业属于哪个课程	2026年春季软件工程 - 北京航空航天大学
这个作业的要求在哪里	[l.1] 个人作业：阅读与提问
我在这个课程的目标是	了解软件工程的思想和开发流程，学习团队开发的规范，提高软件开发能力
这个作业在哪个具体方面帮助我实现目标	加深对软件工程方法的理解，训练自己进行思考表达能力。

---

提问

问题一：在 AI 辅助编程时代，代码行数是否仍然是重要指标？

出处：：

在《构建之法》第3章软件工程师的成长中，作者在讨论软件开发规模和复杂度时提到，代码规模的增加往往意味着系统复杂度的增加，也会带来更多潜在缺陷和维护成本。因此在软件工程实践中，开发者通常需要控制系统规模，并通过模块化设计来降低复杂度。

问题：
在传统软件开发环境中，代码行数往往被视为一个需要控制的重要因素。代码越多，意味着系统越复杂。因此很多软件工程实践都会强调保持代码简洁，并避免不必要的重复代码。
课程也对于代码行数有明确要求要在一万行以上，但在当前 AI 辅助编程工具逐渐普及下，代码生成的成本已经明显降低。例如通过 AI 可以快速生成模板代码、测试代码甚至一些基础模块。

因此我开始思考：如果代码可以通过AI快速大批量生成，代码行数是否仍然是衡量软件复杂度和质量的重要指标？
在我平时写程序的过程中，很多代码已经可以通过 AI 工具自动生成，例如测试代码。这些代码虽然会增加整体代码量，但并不会明显增加开发成本。

问题二：程序员自测为何强调“单步调试”，而不是单元测试？

出处：

《构建之法》第 4.4.2 节 “代码复审的步骤” 中提到：

程序员必须测试过代码。什么叫测试过？最好的方法是在调试器中单步测试。

如果作者都不能让程序执行到那些分支，那谁能保证那些错误处理的正确性呢？
同时建议使用 OutputDebugString`等方式监视程序的控制流。

---

问题:在本书前面的章节中，作者介绍了Unit Test和Regression Test。在进行Code Review之前，应该通过单元测试和自动化测试来验证代码。
然而在这里作者强调的是 “在调试器中单步调试”，这种方式看起来比较原始，而且效率较低。

结合我查阅的一些资料，目前许多开源项目如 Linux、Kubernetes 等的开发流程通常是先提交代码并运行CI自动化测试，通过后再进行Code Review，因此自动化测试与代码复审往往是结合使用的。因此我在思考，书中提到的“单步调试”是否只是程序员自测的一种基础手段，用于理解代码执行路径。

问题三：独立的专职 QA（测试角色）是否在现代 DevOps 流程中逐渐失去必要性？

出处：

第14章 质量保障 14.2节 “软件的质量保障工作”

“有些成功人士和成功的公司号称没必要设置独立的测试角色（Test），你怎么看？一位曾在微软和雅虎上工作过的程序员,有这么一个论断：大多数的开发团队并不需要一个独立的测试角色。
随后，作者在书中明确表达了自己的立场：“首先，有分工是好事，软件团队中应该有独立的测试角色……独立的测试角色从用户的角度出发验证产品质量。独立专业的测试等同于代表客户对产品进行认证。”

问题：独立的专职 QA（测试角色）是否在现代 DevOps 流程中逐渐失去必要性？

事例或资料： 我查了资料，有这些说法：那篇《我们需要专职的QA吗？》以及现代DevOps理念指出，设立专职的独立QA团队往往会产生一种严重的“副作用”——开发人员会产生“反正有QA兜底”的心理，导致他们不再对自己的代码质量负全责，习惯性地把半成品代码“扔过墙”给测试去测。而在当今的硅谷头部企业，测试文化已经演变为 "You build it, you run it"（谁构建，谁负责）。QA 的角色正在消亡或转型为 QE（Quality Engineering），他们不再负责最后的签字验收，而是专门为开发人员提供自动化测试框架和工具，让开发人员自己完成测试。

我反对作者过于绝对地坚持“必须有独立测试角色”的观点。为什么书里认为“开发人员自己测试”就一定等同于“幼稚的、事太小的、非商业级的开发” ？作者用电器需要第三方安全认证、或者药品需要检验来比喻软件测试，但这忽略了没有了独立的测试人员，并不意味着“没有测试”。它只是将测试的责任前置并融合到了开发角色中。

问题四：在并发编程中，依赖压力测试来发现死锁是否不严谨？

出处：

第13章 软件测试 13.2.9节 “压力测试”

“注意，压力测试的重点是验证程序不崩溃或产生副作用 最常见的问题是：内存/资源泄漏 进程/线程的同步死锁问题，在压力下一些小概率事件会发生，看似完备的程序逻辑也会出现问题 。”

问题： 面对操作系统级别的多线程死锁漏，用压力测试这种概率性的黑盒跑法，难道不是一种不严谨的吗？
根据我在《操作系统》课程中学到的知识，死锁的产生必须同时满足互斥、占有并等待、非抢占等。在理论上，我们可以通过使用银行家算法来静态避免死锁。对于内存泄漏，Java有垃圾回收GC。
我的困惑是：我认为死锁和内存泄漏应该在系统设计和代码架构层面被从逻辑上彻底消灭。为什么书中将其归结为要在“压力测试”中去发现？如果在压测中偶然发现了死锁，但由于并发状态的不可重现性，我们很难定位根本原因。这是不是一种本末倒置？

问题五：为何软件工程总是着重“重构”而非“重写”？

**出处： **

第15章 稳定和发布阶段 15.1.3节 “招数：设计变更”
在讨论如何处理烂代码时，“重构——在尽量保持原有界面的基础上优化部分代码。重写——重新实现原有功能 。”警告程序员不要轻易冲动去引入新技术或者重写原有模块，要求用 DCR 来严格管理。

提出问题： 当软件的面向对象设计从一开始就存在致命缺陷时，“重构”难道不是在浪费时间吗？

根据我的实践，在做OO作业电梯时，有时候初期为了赶进度，代码里会出严重的耦合。如果要一步步重构，拆分接口、往往会导致代码越改越乱。而直接废弃这部分烂代码，用清晰的OOP模式重新写一遍，不仅速度快，而且逻辑更清晰。
我反对作者完全反对“重写”。重构的前提是原有代码有良好的基础。如果地基已经腐朽，为什么软件工程认为重构比推倒重来更好？