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

个人作业：阅读与提问

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15608
我在这个课程的目标是	学习软件工程的基础知识
这个作业在哪个具体方面帮助我实现目标	帮助我构建了实现软件工程项目所必需的思维方式与工作模式

---

阅读提问

问题 1：AI能否代替结对编程的领航员角色

我看了这一段文字：
每人在各自独立设计、实现软件的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的那一位。这样，程序中的错误就会少得多，程序的初始质量会高很多，这样会省下很多以后修改、测试的时间。具体地说，结对编程有如下的好处：

（1）在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作能有更强的解决问题的能力。

（2）对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。

（3）在心理上, 当有另一个人在你身边和你紧密配合, 做同样一件事情的时候, 你不好意思开小差, 也不好意思糊弄。

（4）在企业管理层次上，结对能更有效地交流，相互学习和传递经验，能更好地处理人员流动。因为一个人的知识已经被其他人共享。

总之，如果运用得当，结对编程能得到更高的投入产出比（Return of Investment）。

有这个问题：
在AI编程技术得到广泛应用的今天，AI是否有能力替代结对编程中的“领航员”角色？

我查了资料，有这些说法：
目前业界已经广泛提出了“AI结对编程（AI Pair Programming）”的概念。很多研究和开发者反馈表明，大模型不仅能够实时补全代码，还能进行代码复审、生成测试用例，并在重构和Debug时提供极高的效率。因此有些人会提出AI是一个完美的、不知疲倦的领航员，完全可以胜任结对编程里领航员的角色。

根据我的实践，我得到这些经验：
作为一个经常使用AI技术辅助编程的人，大模型诞生以来我的几乎每项工作都离不开大模型的辅助与检查。虽然大模型能够给出当前代码实现的问题与辅助实现的功能，但它并没有带给书中所说结对编程的心理上的满足感。由于面对的不是一个有血有肉的人，我在和它交流时不会考虑它的感受，并且默认它对于代码是“全知全能”的，在实际编程时我们的关系更接近依赖而非合作。虽然我还没有实际体验过和另一个人结对编程是什么样的，但我确信这会是一种完全不同的感受。

但是我还是不太懂，我的困惑是：
既然AI无法提供人与人结对编程时的心理激励作用，那么这是否说明结对编程是无法被AI替代的？如果随着AI代码生成效率的提升，结对编程的投入产出比小于AI结对编程，那么是否还有必要为了促进交流与提供心理作用而保留结对编程的形式？

---

问题 2：自动化测试脚本是否会让开发者忽视测试设计？

我看了这一段文字：
“在单元测试中，VSTS 自动为你生成了测试的骨架，但是你还是要自己做不少事情，最起码要把那些 //TODO 的事情给做了。”
“从上面这个例子可以看到创建单元测试函数的主要步骤：

（1）设置数据（一个假想的正确的E-mail地址）；

（2）使用被测试类型的功能（用E-mail地址来创建一个User类的实体）；

（3）比较实际结果和预期的结果（Assert.IsTrue(target!= null);）。

现在可以运行单元测试了，同时可以看看代码覆盖报告“code coverage report”，代码百分之百地都被覆盖了。

当然这时候的代码还有很多情况没有处理，同学们在台下杂曰——

处理空的字符串，长度为零的字符串，都是空格的串……
”

有这个问题：
如果开发工具能够自动生成测试代码的框架，这种自动化是否会让开发者忽视测试设计的重要性？

我查了资料，有这些说法：
1.在许多开发工具里（例如IDEA等）都集成了自动生成测试类和测试方法的功能，开发者可以很容易地生成测试代码，但有时可能导致开发者把测试当成一种机械步骤，而不是一个需要认真设计的过程

2.在软件工程领域，有研究指出：高质量的单元测试需要良好的测试设计，自动生成测试代码只能提供结构，而不能代替测试思维。例如测试设计通常需要考虑等价类划分、边界值分析、异常路径测试、状态变化测试等，这些都是自动生成代码无法完全替代的。

根据我的实践，我得到这些经验：
当开发工具（例如IDEA）能够集成自动生成测试代码的功能时，往往只需要填一些简单的测试就可以满足测试要求。而在实际的综合测试中，这些测试往往显得不够用，最大的原因是对于每个类进行的单元测试往往不能代表组合情况下程序仍然保证正确性，最终还是要依赖其他的方法（例如测评机生成的组合数据）来筛查这些问题。

我的困惑是：
讲义主要介绍了：如何使用工具生成测试、如何运行单元测试、如何查看代码覆盖率，但对于 “如何设计高质量的测试用例” 的讨论相对较少。那么，虽然开发工具可以自动生成测试代码的框架，提高开发效率，但这种自动化是否可能让开发者忽视测试设计，从而导致测试质量下降？

---

问题 3：在大型软件工程中，追求某些局部优化解法，是否会破坏系统的通用性和可维护性？

我看了这一段文字：
在“分析和开发方法”章节：
回到前面提到的“鸡兔同笼”问题，人们还想出了另一解法：

假设笼子里所有的兔子都坐在地上，举起它们的前腿，这样，三十五个动物都有两只腿和地面接触。那么，这个笼子里原来的“下有九十四足”就变成了“下有七十足”。兔子一共举起了二十四只前腿，每只兔子都有两只前腿，那么笼子里就有十二只兔子，那么三十五只动物的另外二十三只就是鸡。

我们怎么用数学公式或图形来表达这一方法呢？这一方法如何能推广到“果冻搬砖”的问题中呢?

有这个问题：
作者在这里提出鸡兔同笼问题的另一种解法，背后的原因应该是为了鼓励作者在某些特殊情境下做一些对于特定问题的优化以实现提高效率等优化。但是在书里所说的软件工程的设计与实现里，最经常提到的就是设计的通用性以及在需求发生改变时的可维护性。那么在这个情境下，仍然采取这种取巧的方法是否可取？在这个情境下最简单的反例就是如果动物种类的数量变了，这种方法就不适用了。

我查了资料，有这些说法：
克努斯曾提到过： “过早优化是万恶之源。” 这种“抬腿解法”本质上是一种针对特定约束（只有两种动物、腿数固定）的极致优化，但在需求未定型前，这种优化往往会锁死系统的扩展性。

《重构》中马丁·福勒提到，如果代码中充满了只有天才开发者才能理解的“奇技淫巧”，那么这段代码就具备了“认知负担”，是难以维护的。

根据我的实践，我得到这些经验：
在初学C语言程序设计或者在有限时间内解决问题（例如上机）时，我一般会采用这样的技巧来提高效率以及减少编程时间。但是针对一个千行乃至万行级别的大项目（例如OO的单元作业、编译器）时，我的经验会告诉我尽可能的规避这种牺牲系统性换取效率的方式。我曾经经历过这样的教训，在OO的第一次迭代时为了节省时间在一个处理中使用了简单但不系统的写法，但就是这种写法导致在后两次迭代时bug都出自这个第一次作业埋下的坑中，最后面临整体重构的境地，浪费的时间远高于节省出来的时间。

我反对作者在这里提出的观点：
我认为作者在这里可能并不是在鼓励我们去写这种取巧的代码，而是试图让我们思考对于不同算法建模的抽象层次。但我反对作者在强调软件工程目标是解决用户需求的同时，提出乃至推荐这样一种具有算法竞赛色彩且应用范围明显变窄的新解法。我认为软件工程的精髓在于管理复杂性，而抬腿解法虽然展现了对于问题的独特思考，却增加了团队沟通的复杂性。

---

问题 4：软件项目的工程支架是否会成为一种负担？

我看了这一段文字：
软件工程的质量要靠软件工具和软件流程来保证， 大家看过正在建设中的高楼， 半完工的楼顶上矗立着巨大的塔吊。这个塔吊不是用户需求的一部分 （用户希望完工的楼房上面没有塔吊！），但是，这是建筑工程上不可缺少的环节，那么怎么把塔吊顺利地安装上，随着楼房的增高而增高（动画， 迪拜塔的建设），让塔吊高质量地工作，怎么做安全检查，防止它倒下来？ 这就是工程的要求。

软件工程中，也有类似脚手架，塔吊这样的工程系统，工具和流程。 软件的源代码管理工具（source code control system），加上构建系统 （build system）, 能保证一个复杂软件能在多个角色，多个团队的合作下，按时以合适的质量发布。 如果你写一个Hello World 程序， 当然不需要这些工具， 就像你用儿童积木搭房子过家家，你自己高兴，但这不是建筑工程。

有这个问题：
在现代高频率软件开发的项目过程中，这些源代码管理和构建系统的“脚手架”往往呈现出比业务代码更快的复杂度增加速度。当一个项目为了实现所谓的高质量的工程质量而引入了复杂的支架系统时，我们如何评估这些支架带来的负载是否已经超过了它所带来的对于开发效率的提升？如果“支架”本身需要随着需求频繁重构，那么它是否失去了本身应该有的作用？

我查了资料，有这些说法：
在软件行业，这种“支架比楼重”的现象已有许多经典的理论探讨：
1.塞斯·高汀的剃牦牛理论： 描述了一种为了完成一个小任务，不得不先去完成一系列看似无关、实则不断套娃的繁琐工作（如修流水线、升级编译器、重配容器环境）。
2.有研究指出，每引入一个自动化工具来解决旧的复杂性，往往会由于该工具的学习、配置和维护而产生新的“次生复杂性”。

根据我的实践，我得到这些经验：
我虽然没有参与过大型软件的开发，但我在进行大模型微调实验时也体会到了修改支架的麻烦。对于一个微调模型的项目，他它的核心代码可能只有几百行，但是为了实现分布式训练、监控显存和配置多机环境等，我可能需要写上千行的 YAML 配置和 Shell 脚本。一旦环境发生微小漂移（例如 CUDA 版本升级），整个系统需要调整很多配置才能重新适配。尤其是复现别人的代码时，经常因为版本不一致等问题报错。

在这里我的困惑是：：
作者使用“塔吊”和“脚手架”对软件工具进行类比，但是我认为这样的比喻有严重问题。现实中的塔吊在楼盖好后是可以撤走的，但但软件的构建系统和源码管理逻辑是深度嵌入代码肌理的，一旦外部需求变化导致支架需要重构，往往意味着“支架”本身也需要进行大量改动，这样的抽象与辅助往往背离了帮助开发的初衷。我认为作者需要对这些工具的“自重”进行进一步的说明与分析。

---

问题 5：在互联网细分领域都被占满时，NABCD 模型真的能帮助我们产生创新吗？

我看了这一段文字：
互联网时代对于创新者来说, 既是一个伟大的时代, 又是一个糟糕的时代。你有很多机会做出影响世界的产品，但是似乎任何想法都被别人想到过了……
在《现代软件工程》这门课里，同学们不能穿新鞋，走老路……我们要做实用并且创新的项目。

那我们怎么提出新的创意，怎么说服别人我的创意是靠谱的？

下面是一个比较系统的框架 —— NABCD 模型：
N (Need) 需求
A (Approach) 做法
B (Benefit) 好处
C (Competitors) 竞争
D (Delivery / Data) 交付与数据

有这个问题：
作者提出 NABCD 模型来帮助团队系统地分析创新想法，并论证其可行性。但在今天的软件行业中，大量成熟产品已经覆盖了几乎所有常见需求，同时大型互联网公司拥有资源、数据和渠道优势。对于学生团队或者小型团队来说，即使能够通过 NABCD 清晰地论证需求、方法和价值，也可能仍然难以在真实市场中与现有产品竞争。

那么，NABCD 模型究竟是在帮助我们“产生创新”，还是更多地在帮助我们“论证一个已经存在的想法”？
换句话说，如果真正困难的是“找到一个值得做的想法”，而不是“分析一个想法是否合理”，那么 NABCD 是否只能解决创新过程中的后半部分问题？

我查了资料，有这些说法：
1.在创新研究中，有学者认为 创新往往不是从分析框架开始，而是从长期的领域经验和用户观察中产生。
2.在现实的软件创业环境中，小团队成功的路径往往是 从极小的细分需求（niche market）切入，通过持续迭代逐渐发展，而不是一开始就设计一个完整且宏大的产品方案

根据我的实践，我得到这些经验：
在课程项目或作业中，我们往往是先想到一个“看起来还不错的点子”，然后再尝试用各种方法去证明这个点子的合理性。例如做一个学习打卡系统、进度共享系统。但经过调研，需求其实已经被很多产品解决（例如 Notion、Todo、各类学习软件）；而团队提出的创新点往往只是增加一个小功能；最终项目更多是为了完成课程，而不是真正被用户使用。

因此，我的困惑是：：
如果创新最困难的部分是 发现新的问题和机会，而 NABCD 更像是一个 分析和论证想法的框架，那么在软件工程教育中，仅仅强调 NABCD 是否会让学生误以为“只要把框架写完整，就是一个创新项目”？或者说，我们是否需要更多的方法去培养创新能力？