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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	综合应用软件工程知识，团队协作开发一个具备实际应用价值的软件，从需求分析、设计、开发到测试和部署，完整经历软件开发生命周期，提高工程实践能力。
这个作业在哪个具体方面帮助我实现目标	掌握软件工程的开发流程和各部分的具体细节

问题一 ：如何确定 MVP（最小可行产品）的最小功能集，既能满足用户需求，又不过度简化？

书中提到：

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

但是，如何确定哪些功能属于“最核心”，书中并未给出具体的方法。

我的经验：

• 在设计最小功能集时，会面临如何区分“核心功能”和“非核心功能”的问题。最初，我总觉得核心功能应该是最直观的功能，比如最基本的操作流程。然而，随着用户反馈的积累，我发现，并非所有直观的功能都是必不可少的。有时，最核心的功能并不是最显而易见的，而是那些可以解决用户痛点、提升体验的部分。

我的疑问：

• 如何判断哪些功能是“最小但可行”的？ 书中给出的案例是直觉性的（比如“观察用户点击量”），但如果是更复杂的产品（如在线教育平台、AI 辅助软件），如何科学地确定 MVP 需要哪些功能？
• 是否有一套系统化的方法来定义最小功能集？ 例如，是否可以通过用户需求分析、竞品分析、数据驱动等方式，来决定 MVP 应该包含哪些功能？

问题二：任务的估计时间太长时应当分解，但如果分解破坏了任务完整性怎么办？

书中提到：

“如果一个任务的估计时间过长（如超过16个小时），那么它应该被进一步拆分。”

我的经验：

• 在实际项目中，我曾遇到过任务被拆得过细的情况，导致团队成员只关注自己的小部分，而忽略了整个系统的集成，最终导致交付质量下降。

我的疑问：

• 书中建议拆分任务，但未讨论如何判断任务的“完整性”是否受到影响。是否有明确的标准或经验法则可以用于评估？如何在拆分任务和保持完整性之间找到平衡？

问题三：BUG的定义

书中提到：

什么是Bug呢？简单地说，软件的行为和用户的期望值不一样，就叫Bug。例如，某聊天软件启动时就崩溃了，用户期望这个聊天软件不能崩溃……

我的经验：

• 现在的手机普遍都有各种手势操作，比如安卓手机中存在从左右边缘滑动就可以返回到上一个界面，但是各家手机的手势不尽相同，对于习惯了一款手机的人来说，如果换到另一个品牌的手机，可能会出现误操作，即用户的潜意识和手机的实际表现出现了偏差，这样的话也算是软件的行为和用户的期望值不一样，但是我认为这不应该是bug，而是手机和用户的契合度（磨合）不够。

我的疑问：

• 如果将bug定义为软件的行为和用户的期望值不同，那么“软件的行为”指的是所有的行为还是也定的行为？如果“软件的行为”泛指所有的行为，但是，在我看来，每个用户的习惯和想法都不尽相同，不可能做得到迎合每一个人的想法，只能说软件尽可能适配大多数人的习惯和想法，这是个人习惯的差异。所以bug是否应该有更为严谨的定义？

问题四：单元测试一定要最熟悉代码的人来写吗？

书中提到：

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

我的经验：

• 在之前很多次作业中，我的代码出现了错误，但是我自己也用了很多测试样例，也写过很多单元测试，但就是找不到bug，但是求助于同学或者助教之后，bug很快便解决了。

我的疑问：

• 自己写的代码自己最熟悉是没有任何问题的，但是当程序出现bug时，自己同样可能陷入到寻找bug死循环中无法走出，俗话说“当局者迷，旁观者清”，也许你自己很难看到问题出现在哪，因为你的思维可能固化，考虑问题不全面所致，或者说受限于自己的能力，很难写更好的测试了，这时，其他人如果写一个单元测试，可能会补足你单元测试中考虑的不全面的问题。再者说，对于一个擅长写单元测试的人来说，读代码加上写单元测试的时间可能会比自己写单元测试的时间还要短，这样在软件开发中是否提高了效率？所以，单元测试是否应当有写代码的人来写，这一观点是否不太准确？

问题五：结对编程是否只是理论上的可能？

书中提到结对编程的好处如下：

1.在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。两人合作，还有相互激励的作用，工程师看到别人的思路和技能，得到实时的讲解，受到激励，从而努力提高自己的水平，提出更多创意。
2.对开发人员自身来说，结对工作能带来更多的信心，高质量的产出能带来更高的满足感。
3.在企业管理层次上，结对能更有效地交流，相互学习和传递经验，分享知识，能更好地应对人员流动。

好处固然存在，但是我认为，结对编程的弊端也是不可忽视的。
缺点如下：

• 如果两个人的水平差距过大，那么再配合上就存在来着可能性。一是水平高的人自己把事情干完了，水平低的人完全在摸鱼，这样水平低的人也学不到东西，一直这样下去，水平高的人的热情会逐渐被消磨殆尽，结对编程可能也就名存实亡了。二是水平高的人教水平低的人如何去做，但是这种情况要考虑水平高的人是否愿意去教，是否对水平高的人来说是一种时间的浪费？
• 在两人水平差不多的情况下，的确可以互通有无，但是在企业中，每个人工作都是为了利益，在结对编程中可能存在因利益分配不均导致的分歧，这样也是不利于两人之间的合作和信任的。