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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件工程知识和软件开发中的通用方法，提升实际项目开发的能力，参与从需求分析、设计、编码、测试到维护的完整软件开发流程，并完成一个完整、实用、好用的软件
这个作业在哪个具体方面帮助我实现目标	学习软件开发中的通用方法，领会其中工程化的方法和思想

问题一：敏捷开发中的“适应性”是否意味着需要接受任意的需求改动？

书中提到：

敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势

需求变化是软件开发中的不稳定因素，可能会带来软件质量的变化。我认为在工程实际中，不能一味地对不稳定性采取欢迎态度，如果需求更改太过频繁，导致项目没有稳定方向，团队往往会陷入混乱，导致进度失控等不可预料的后果。同时，团队的士气也可能受挫，程序员会因为反复修改而感到沮丧，降低工作积极性。Scrum 指南也提到 Product Owner 负责需求管理，也提到 Sprint 期间不应改变 Sprint 目标，这与“需求可变”似乎有冲突。

书中强调了“适应性”，但我认为应当思考变更的边界，探讨如何判断某个变更是否应该被接受，或者设置一个确定的时期，只有在特定时间窗口才能修改需求。

问题二：如何更好地与客户和最终用户合作？

书中提到：

MSF有一套思想框架——9条基本原则：... 9.与顾客合作 (Partner with internal and external customers)

MSF强调，软件开发是一个以用户需求为核心的过程，开发团队应始终与客户保持紧密沟通，确保软件真正满足他们的需求，而不是仅仅满足开发者自己的假设。然而，客户并不总是知道自己想要什么，提出的需求往往是模糊的甚至错误的。例如，客户描述不清，无法提供明确的需求说明；在看到产品雏形后，又改变甚至推翻之前的需求；不同用户群体的需求间有矛盾等等。书中提到开发团队要“理解客户”，但没有深入讨论如何处理这些具体情况。

我认为，开发团队除了与用户多沟通，被动地听取客户需求外，还需要学会引导客户，筛选需求。正如Apple创始人史蒂夫·乔布斯所说，"Customers don't know what they want until you get it done."。对于不同用户的需求冲突，需要尽量寻求平衡与兼顾，但优先满足主要用户的需求。

问题三：用户体验(UX)和功能在软件开发中的优先级？

书中讲述了这样一个故事，核磁共振机通道加宽可以改善病人的检查体验，但会降低扫描成像的质量。一家公司率先选择了加宽通道，一举夺取了大量市场份额，其它公司才纷纷追赶。书中强调用户体验是软件成功的关键因素之一，一个技术先进但用户体验糟糕的产品很容易被市场淘汰。但我认为在用户体验和功能开发之间应该有所权衡，既不过度追求用户体验而影响功能和交付时间，又不过度关注功能而让用户觉得软件难用。

书中没有明确讨论这一权衡，但我认为可以用如下策略：在产品开发早期，功能比体验更重要，快速实现核心功能，做出核心价值；代码成熟后再进行交互优化和UI设计。在完成大部分UI设计后，细节优化可以进行“用户反馈驱动的UX优化”，在不破坏核心功能的前提下优化UX。

问题四：是否应该使用 goto 语句？

在书本的第四章中提到：

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

避免使用goto语句，是我们在大一程设课上就提到的提倡做法，然而此处作者认为只要方便就可以使用。我认为这一做法有待商榷。无论是学界的理论证明还是这两年多的编程实践，都告诉我们只用顺序、条件、循环三种控制流结构是可以解决程序中的所有控制问题的，不应当依赖goto语句。goto跳转语句可能会使程序控制流来回跳转，增加出bug的可能，也使阅读者在阅读代码时需要不断跳转才能读懂代码，增加程序维护的难度。调试时对bug也更加难以追踪到问题的来源，就像编译时的基本块，不知道当前基本块是在哪个基本块后执行的。

《Clean Code》中提到，goto 语句是“坏代码”的典型代表，应通过适当的函数分解和更清晰的条件语句避免其使用。我认为应该通过遵循结构化编程原则，使用更常见和更可维护的控制结构来编码，以提高程序的可维护性。

问题五：回归测试中，基准样例是否会随着代码不断迭代变得过于庞大？

在书中提到：

在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准线。

按照这一原则，在迭代过程中，所有进行过测试的测试用例都应该保存，可以是直接通过的测试用例，也可以是出错但经修复后通过的测试用例。那么随着迭代的不断进行和测试的不断深入，为每个模块保存的测试用例集是否会变得过于庞大？这是否会导致测试的效率问题？书中还提到为每个单元的测试时间应该是几秒钟而不是几分钟，如何平衡测试效率和测试准确性的要求？《Continuous Delivery》中给出了智能测试和增量回归测试的建议，即实现一个测试框架，每次发布时能够评估哪些部分的代码变动较大，从而只运行这部分的测试。我认为这是一个可行的办法。Microsoft在其软件开发实践中采用了测试影响分析的方法。通过该方法，开发团队可以分析哪些代码变动会影响哪些功能，自动挑选相关的回归测试用例进行执行。这个方法有效减轻了回归测试样例数量增加带来的压力。