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

《构建之法》阅读提问

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	个人第一次作业
我在这个课程的目标是	掌握现代软件工程的核心思想与实践方法，提升团队协作与项目开发能力
这个作业在哪个具体方面帮助我实现目标	通过泛读教材并主动提问，培养批判性思维，为后续深入学习打下基础

---

阅读提问

问题一：单元测试追求100%覆盖率在实际工程中是“银弹”还是“奢侈品”？

源于第2章 “个人技术和流程” 中关于 “好的单元测试的标准” 的讨论。书中强调单元测试应该覆盖所有代码路径，包括错误处理路径，以保证代码质量。

在之前的课程大作业中，我遇到过类似 char* tmp = (char *)malloc(...); if (tmp) { ... } else { ... } 的代码结构。在常规环境下，malloc 失败进入 else 分支的概率极低，导致很难针对“内存申请失败”这一错误处理路径编写有效的单元测试，最终测试覆盖率卡在99%无法达到100%。我搜索了相关资料，发现业界确实存在 《100%代码覆盖率的悲剧》 这类讨论，指出盲目追求覆盖率可能导致开发者写出“为了测试而测试”的胶水代码，而非真正提升质量。

在实际的软件产品开发中，时间紧、任务重，我们是否必须不计成本地追求100%的覆盖率？特别是针对那些发生概率极低、模拟条件苛刻的错误处理路径（如内存耗尽、磁盘写满），有什么更简单高效的测试策略？这究竟是质量的门槛，还是对效率的妥协？

问题二：goto 是“洪水猛兽”还是“灵丹妙药”？它的使用边界在哪里？

源于第4章 “两人合作” 中关于 “代码设计规范” 的讨论。书中为了论证代码风格的清晰直观，举了一个例子：为了函数有单一的出口，可以使用 goto。

从大一学C语言开始，几乎所有老师和教材都在强调“goto 语句会破坏程序的结构化，使代码难以阅读和维护，能不用就不用”。这种观念已经根深蒂固。我查阅网络资料，发现大多数技术社区也对 goto 持反对态度，因为它会使程序的静态结构和动态执行流程严重不符，增加调试和编译优化的难度。

书中观点与我的既有认知产生了强烈矛盾。我知道在Linux内核等一些底层代码中，goto 常被用于集中处理错误退出，确实显得很简洁。那么，在实际开发中，我们究竟应该如何权衡 goto 的利弊？有没有一个比较清晰的“红线”或“最佳实践”来判断什么情况下使用 goto 是利大于弊的？

问题三：敏捷开发中的“每日立会”会不会变成形式主义的“站会表演”？

源于第6章 “敏捷流程” 中关于 “Scrum术语” 的介绍。书中提到“每日立会”能强迫每个人向同伴报告进度，迫使大家把问题摆在明面上。

我在网上看到一些吐槽，说这种“每日”的节奏过于死板。如果一个功能需要三天才能完成，开发者可能连续两天汇报“实质性进展不大”，这会带来无形的压力，导致成员为了“显得有进展”而汇报一些细枝末节的琐事。同时，准备和参加例会本身就有时间成本，如果团队沟通效率高，会不会反而成为一种打断心流状态的负担？

如何避免每日立会沦为一场“表演”或“汇报工作”的形式主义会议？如果一个功能确实无法进一步拆解为可在一天内完成的子任务，在立会上如何有效沟通？书中有读者提问类似问题，老师的回复是“工作要不断细化为可以短时间完成的小任务”，但在复杂业务逻辑下，这种拆解有时非常困难，这该怎么解决？

问题四：结对编程如何避免变成“一个在开车，另一个在睡觉”？

源于第4章 “两人合作” 中关于 “结对编程” 的详细描述。书中描绘了两人肩并肩、平等互补地工作的美好画面。

我在知乎和一些技术社区看到过这样的讨论：如果两人水平差距较大，很容易变成高水平的程序员全程掌控键盘，低水平者因为跟不上思路而被迫“围观”，最终沦为“打酱油”的角色，项目结束后依然没什么收获。如果按时间粒度频繁轮换（比如一小时一换），编程需要“预热”和进入“心流”状态，频繁打断会不会反而降低效率？

在结对编程中，如何设计具体的协作机制，才能确保双方（尤其是水平较弱的一方）都能深度参与并有所成长？对于不适合被打断的复杂逻辑设计，应该如何灵活调整“驾驶员”和“领航员”的轮换策略，而不是机械地执行？

问题五：修复Bug和开发新功能，在优先级上真的存在“贪心最优解”吗？

源于第13章 “软件测试” 或第9章 “项目经理” 中的相关内容。书中提到了“小强地狱（Bug Hell）”的概念，即当Bug数量超过阈值则强制开发者去修复。

我的第一直觉是，Bug既然是软件中的“毒瘤”，按照“越早修复成本越低”的测试经济学原理，发现Bug应该立刻修复才对。但在实际中，产品经理往往催着要新功能，修复旧Bug看起来像是在“原地踏步”，无法体现在产品更新日志上。

在实际迭代开发中，如何科学地制定修复Bug和开发新功能的优先级策略？那种“Bug数量超过阈值再集中修复”的方式，虽然能保证开发进度，但会不会导致Bug之间的相互干扰，使得后期修复成本指数级上升？有没有更动态、更精细化的管理模型来处理这个矛盾？