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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件工程相关的基础知识，并在实战中运用这些知识
这个作业在哪个具体方面帮助我实现目标	了解软工、学习软件工程相关的基础知识

阅读提问

1. 关于单元测试

   我阅读了书中关于单元测试编写者的这一段文字：

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

   我认为作者这样的观点有些过于绝对了。作者认为代码的作者最了解代码，所以最适合写单元测试。但我觉得不能将单元测试完全交给代码作者完成。虽然代码作者应当参与单元测试，但完全由作者本人包揽可能会降低测试的有效性，我们需要引入外部视角。如果单元测试全部由代码作者本人编写，可能会采用与编写代码时完全相同的逻辑来进行测试，这可能导致一些边界情况的遗漏，又或许作者本身对需求的理解就有所偏差，那额他的单元测试同样也会带有盲区。

   因此在实际的软件工程中，我们是不应该局限于只由代码作者本人编写单元测试？比如采用团队内交叉测试，或代码作者编写基础用例的基础上加上其他人的代码审查，是否是一种更为合理与健壮的实践方式？

2. 我阅读了书中3.2节关于“过早扩大化/泛化”这一节的内容，其中提到了有些程序员为了解决特定环境下的具体问题，往往会想要“做一个平台，处理所有类似的问题”。作者通过“画扇面”的相声类比了这种追求“大而全”导致项目烂尾的现象，并引用了Linux诞生时的名言：

   “I'm doing a (free) operating system (just a hobby, won't be big and professional...)”

   用来佐证从小处着手的必要性。

   基于以上内容，我的疑问是：在实际的软件工程开发过程中，我们究竟该如何界定“过早泛化”与必要的架构设计之间的边界？在上学期的OO第一单元，由于缺乏相应的设计经验，我在最开始时没有进行好的架构设计，导致后面表达式解析器的功能逐渐增加时进行了多次大范围重构。书中劝阻大家从开始就设计通用框架，认为这是“凌云壮志”但不切实际。可对于一个需要多轮迭代开发的程序，缺乏前瞻性的架构设计很容易变成技术债。而且Linus当年虽然口头上说Linux只是个hobby，但Unix本身却具备着优雅且高度泛化能力的底层架构思想。由此引发了我的疑问：对于我们学生而言，在做一个有一定复杂度的项目时，到底该“先跑通一个缺乏抽象的粗糙原型”，还是“先花时间设计一个具有一定泛化能力的基础框架”？书中的观点是否在一定程度上矫枉过正，忽略了前期合理抽象对后期工程演进的积极作用？

3. 在阅读到5.3.4节RUP统一流程的介绍时产生了一点疑问。书中介绍RUP时提到：“从瀑布模型开始的各种模型都有一个共同点：重计划，重事先设计，重文档表达。这一类的方法中集大成者要算 Rational 统一流程（RUP）”，在介绍RUP的四个阶段时，又提到“RUP在大尺度上像瀑布模型，在每个阶段内像迭代模型“。既然RUP作为”重计划、重文档“的集大成者，它又是如何在每个阶段内部真正做到“像迭代模型”那样灵活的？这难道不矛盾吗？
   基于我查找的资料，现代软件工程开发法中流形的敏捷开发的核心价值观之一就是”个体和互动高于流程和工具，工作的软件高于详尽的文档“。而在我们平时的课设或小型项目组队开发中，如果一开始就写了非常详尽的需求文档，后续编码中如果发现需要调整功能，再回过头去同步修改那些庞大的文档会非常耗费时间与精力，导致大家最终常常放弃维护文档。那么既然RUP在每个阶段内是迭代的，是否会意味着大量的需求变化与调整？RUP又是如何处理频繁变化与自身“重实先设计、重文档表达”之间的冲突的？

4. 在阅读到6.2节的敏捷开发流程时产生了一点疑问。书中指出：

   把一个任务从产品层级的描述逐步细化到技术实现层面，是很需要技术能力和交流能力的。

   由此我产生了一个疑问：面对时间压力，我们究竟该如何将一个相对模糊的产品需求合适的划分为多个可以立即放入Sprint的具体任务？

   业界在敏捷开发中通常会使用“用户故事”来描述需求，并推崇使用INVEST原则，即“独立、可协商、有价值、可估计、小、可测试”来进行任务拆分，并且书中也指出，只有将任务拆分的足够小且清晰，才能进入到Sprint Backlog。但在实际的短周期冲刺中，如果花费过多时间在任务拆分上，敏捷开发不又变成了“小瀑布模型”了？反之，如果为了赶时间而在任务需求仍然模糊时，冒着风险先进行尝试，不仅像书中所说容易返工，似乎也违背了软件工程追求高质量的初衷。在实际的企业敏捷开发中，有没有什么可落地的流程、方法论或工具，能够辅助团队在有限的时间内，既快速又合适的万层这种从“模糊需求”到“具体冲刺任务”的跨越？

5. 在阅读7.2.3节中对于MSF的描述时产生了一点疑问。书中说：

   “MSF 提倡自下而上的计划，每个人有充分的权力估计并决定自己的任务需要多长时间，而不是上级交给的时间……领导在项目中的角色是‘支持成员完成任务’，而不是‘控制成员，迫使他们完成任务’”

   在实际操作过程中，“充分授权和信任”是否包含了一个隐藏前提条件，即团队成员必须具备足够成熟的专业技能，以及准确的时间评估能力？在我的实践过程中会发现，如果组长完全采用自下而上的方式让组员自己评估时间，不去规划ddl，组员经常会因为自身的拖延习惯或遇到预期外的技术问题，导致进度不及预期。如果组长仅依靠工具去记录进度而不去主动问询或干预，到项目后期或许会面临进度大面积延误甚至无法交付的风险。书中所说的“被授权的人会承担起自己对项目的责任”应该只能建立在团队成员都是成熟工程师的基础上。对于像我们这样缺乏工程实践经验的团队来说，如果在缺乏准确判断力的情况下进行完全的放权与信任，是否会导致项目的失控？作为这种不够成熟的团队的负责人，又应该如何把握”帮助解决“与”主动把控进度“之间的界限？