北航软件工程 [l.1] 个人作业：阅读与提问

北航软件工程 [l.1] 个人作业：阅读与提问

项目	内容
这个作业属于哪个课程	2026年春季软件工程 (北京航空航天大学 - 计算机学院)
这个作业的要求在哪里	[l.1] 个人作业：阅读与提问
我在这个课程的目标是	学习融会软件工程理论，参与真实项目的开发全流程，积累软件开发的经验
这个作业在哪个具体方面帮助我实现目标	通过泛读教材，大致了解软件工程与敏捷开发

阅读提问

问题一：如何平衡单元测试与复杂逻辑？

在2.1中，作者描述了单元测试的价值以及提出了“好的单元测试应该具有的标准”：

单元测试应该在最基本的功能 / 参数上验证程序的正确性。
单元测试要测试API中的每一个方法及每一个参数。
单元测试应该覆盖所有代码路径。为了保证代码覆盖率，单元测试必须测试公开的和私有的函数 / 方法。

但是这些理想标准在应对现实的复杂逻辑时，往往很难真正落地、按照作者的想法发挥作用。

以Java语言为例，方法是功能点的体现，单元测试需要验证每一个方法是否正确。如果核心逻辑中包含了随机数生成、外部状态依赖或多线程竞争等不确定因素，单元测试甚至无法手动构造出一个多次运行始终保持不变的正确样例。

如果为了让方法“可单元测试化”，一味地对方法进行解耦、拆分，则会衍生出函数调用链变长、一次性数据增多、运行速度下降、代码结构破碎等不良影响。

我的问题是，在实际开发背景下，如何平衡单元测试与复杂逻辑？当遇到非确定性逻辑或因追求可测试性而导致的代码膨胀时，业界通常的解决方案或评价指标是什么？

问题二：结对编程适用于什么场景？

在4.5中，作者大致介绍了结对编程出现的原因以及好处，但同时也列出了一些可能出现的问题，对这些问题作者并未回答。

按照书中的描述，结对编程的初衷是将复审和交流融入编程过程中，在初期提高程序各方面的质量。对于这种模式，我最大的疑惑是，结对编程到底适用于什么场景？

当一个人在编程时，个人需要预先对接下来的编程活动做好初步的规划，按照自己的方式组织进行。当此时加入了另一个人，是否会干扰编程计划，或者讨论中多次出现重构，或者因两人的性格、理念等发生冲突？是否会出现两人过于聚焦眼下的模块而忽略大局？另一方面，结对编程也有“老带新”的意图，这种情况下负责编程和评审的角色应该如何分配？资深人员的经验是否会扼制新生力量的思维创新？

问题三：敏捷开发如何与测试工作相融合？

在第6章中，作者介绍了敏捷开发的原则与流程，强调“尽早持续地交付有价值的软件”以及“欢迎需求变更”。然而，当我尝试将敏捷开发的理念与测试相结合时，产生了以下疑惑：

敏捷开发的快速迭代对测试提出了很高要求，如果每个迭代结束都要做完整的回归测试，手工测试很难满足这种需求，这是否意味着“自动化测试是敏捷的前提”？对于那些难以自动化、或自动化成本极高的测试（如复杂的UI交互、特定硬件兼容性测试），在敏捷流程中应该如何安排？

作者提到，在敏捷开发中，测试人员不再是一个“独立的验收部门”，而是融入团队，要由每个人自己搞定测试。但是如果每个人只编写零散的模块，要如何完成一次成功的测试？个人负责的测试只是指模块的单元测试吗？

问题四：敏捷开发团队要求每一个成员都各技能均衡吗？

在第6章的实例项目燃尽图中，有一个注解提到：

开发人员有5.5名，绝大多数第一次正式接触商业项目和Scrum的团队开发模式。最终完成的工作量为524小时，是预计的1.5倍。

这个差距巨大的数字，是由于程序员不熟练正式项目，还是团队开发模式带来了阻碍？

进一步结合实际思考，我又产生了以下疑问：

在实际运用敏捷开发模式时，是否隐性地对团队构成提出了要求？以传统的开发团队人员组成为例，可以细分为前端、后端、测试等，前端工作不能在后端准备好接口之前开始（或者前端工作非常有限），那么前期团队的工作重心都在后端模块上，前端人员应该如何安排、认领工作？是否需要每一个人都是“全栈”多面手？

另外，如果团队中人员水平差距比较大，如何规划任务的分配，避免资深人员轻松而新手成员举步维艰的情况，或是资深人员被迫承担所有复杂任务而新手成员只能打酱油的情况？（浪费人力资源和影响软件质量）

问题五：每日立会会不会演变成“罚站大会”或“吹牛大会”？

在第6章的关于Scrum流程的介绍中，作者提到了每日立会的核心要求：

大家依次报告：我昨天做了啥？我今天要做啥？我碰到了哪些问题？

我的疑惑是：

如果在比较复杂的任务下，可能某些成员长期没有进展（比如我目前正在进行的一个项目，确定环境配置花了3天最后还是放弃了这个方向），也许是正常的试错阶段，但在团队面前长期汇报“昨日没有进展，今天保证完成任务”，是不是会挫伤成员的自信心，甚至出现糊弄、瞒报的情况？

如果立会已经陷入了这种形式主义，有没有一些信号能帮助Scrum Master识别出立会已经从协作工具变成了形式主义？同时，这是团队文化或是人员配置、任务分工等的问题，还是Scrum本身的设计在权力结构不平衡的团队中天然会变形？如果已经跑偏了，有没有一些具体可操作的调整方法，能让立会回归本质？