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

个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	2025春季软件工程(罗杰、任健)
这个作业的要求在哪里	I.1个人作业：阅读和提问
我在这个课程的目标是	学习软件工程原理，锻炼团队开发技巧，与队友协同完成一次项目开发
我在这个课程的目标是	了解软件工程原理和团队开发技巧

阅读提问

1. 软件开发中的需求变更管理如何有效实施？在快速迭代的开发环境中，如何平衡需求变更与项目进度？

一个程序中需求变更通常会导致项目进度的延迟，特别是在敏捷开发中，需求频繁变更可能影响团队的工作效率。

• 我查了资料，在通常的软件开发中，一些文献建议使用优先级排序和迭代计划来管理需求变更。 根据我的的开发经历，我发现有时候小的需求变更有时能提升用户体验，但过多变更会导致开发者疲于应付，影响代码质量。
• 但是在软件开发的过程中，尤其是对于软件开发小白而言，往往会出现很多没有预料到的情况，导致为了实现目标结果，需要有较大的需求变更。这时候，软件开发者不免要面对是先满足紧急需求还是先完成软件主体的抉择。以及有时候还要决定，究竟是按原有计划完成软件主体、不考虑新出现的需求，还是为了新需求而重构整体软件？
• 在面对紧急需求时，如何制定合理的决策，以确保项目不受重大影响？是否有必要因为一两个需求而改变整体规划？

2. 在单元测试中如何保证其独立性？如何确保覆盖并保持稳定？

独立性--单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
程序中的各个模块都是互相依赖的，否则它们就不会出现在一个程序中。一般情况下，单元测试中的模块可以直接引用其他的模块，并期待其他的模块能返回正确的结果。
如果其他的模块很不稳定，或者其他模块运行比较费时(如进行网络操作)，而且对于本模块的正确性并不起关键的作用，这时可以人为地构造数据，以保证单元测试的独立性。

• 为了保证单元测试的独立性，往往采人为构造数据。在实际开发中，而代码的复杂逻辑往往依赖于数据库或外部 API。在这种情况下，如何在保证测试独立性的同时，又能确保测试的真实性和可靠性？
• 在oo课程中，前三单元的数据测试主要来源于自己和同学，属于很纯粹的黑盒测试。而在最后一个单元中使用JUnit对类尽心测试，偏向于白盒测试。数据库开发前端时，在课程的前半部分数据库后端没有建好的时候，前端会使用Mock机制来模拟外部API的返回值，做到独立开发。但有时候，Mock 的逻辑可能与真实环境的行为有所出入，导致测试通过但在实际运行中出现问题。在测试时，我们自己内部测试了网页功能，发现依然出了很多问题。
• 如果单元测试完全依赖 Mock，是否会导致测试结果过于理想化，难以发现真实环境中的潜在问题？另外，对于某些涉及多线程、异步调用或时间依赖的代码路径，单元测试该如何确保覆盖并保持稳定？

3. 是否应该由最熟悉的人写单元测试？

单元测试必须由最熟悉代码的人来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。

• 在初步开发中，代码中的bug都往往来源于作者对自己代码的了解程度进行寻找和修改。在提交作业（比如oo课）之前，都会由作者自己先进行充分的测试，然后再提交。
• 但是在测试的时候，往往都会出现问题。因为对于单元测试而言，最难的并不是对代码的了解程度，而是构造多样化数据类型的能力。如果由代码作者自己写测试，对于一些写代码时候就已经疏忽的地方，在测试的时候会更难考虑到，从而导致遗漏bug。事实上在oo、编译等大作业中，很大一部分bug都是通过同学互测、强测等测试中修改完成。尤其是对于缺乏样例构造能力的同学，寻找自己代码的bug更是十分困难。
• 因此，是否该由最熟悉的人写单元测试？我认为最合适的人应该是对代码实现的最终成果有一定了解的人、但并不参与全程开发的人写单元测试最为合适，因为他们既对代码有一定了解，又能提出新的测试方向。

4. 如何在软件项目中有效进行需求优先级排序？ 如何在需求频繁变动的情况下保持优先级排序的有效性？

需求优先级排序对项目成功的重要性。

• 在开发过程中，我一直有这个问题：在众多需求中，如何有效地进行优先级排序，以确保项目成功？
• 我查了资料，有一个很科学的排序方法：使用MoSCoW方法（必须、应该、可以、不会）可以帮助排序。但是当我试图将这个方法应用到之前的项目开发之中，又往往会发现难以将全部的认为都套到该方法之中，对于优先级排序的纠结反而会耽误项目的效率。
• 在我的开发经验中，经常会出现需求的调整变化，而这又使得项目的优先级频繁调整，进而影响整个项目的稳定性。因此我的问题是：如何在软件项目中有效进行需求优先级排序？ 如何在需求频繁变动的情况下保持优先级排序的有效性？

5.如何确定 MVP（最小可行产品）的最小功能集？

MVP的具体做法为：“把产品最核心的功能用最小的成本实现出来（或者描绘出来），然后快速征求用户意见。”

• 软件开发过程中都要先从核心功能做起，但是，如何确定哪些功能属于“最核心”，书中并未给出具体的方法。

• 在数据库开发是，我认为核心功能应当是最底层的项目逻辑和操作流程。然而正如上节课上“飞机救生功能”的讨论，在项目中一些不常用到、但是具有重要作用的功能也十分重要，这些功能并非必需，但是却可以解决用户的痛点，大大提高用户的使用体验。那么这些功能是否应当加入最小功能集中？
• 我的疑问是：如何判断哪些功能是“最小但可行”的？ 书中给出的案例是直觉性的，但对于更复杂的产品，如何科学地确定 MVP 需要哪些功能？