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

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

博客格式描述

项目	内容
这个作业属于哪个课程	[课程社区链接]
这个作业的要求在哪里	[作业要求链接]
我在这个课程的目标是	掌握现代软件工程的核心思想与实践方法，提升团队协作与项目管理能力
这个作业在哪个具体方面帮助我实现目标	通过泛读教材并练习提问，培养批判性思维，加深对软件工程概念的理解与反思

---

阅读提问

在阅读《构建之法：现代软件工程》后，我列出以下仍感困惑的五个问题：

---

问题一：软件工程中"程序"与"软件工程"的边界如何界定？

触发章节： 第1章 概论 —— "软件 = 程序 + 软件工程"

上下文： 教材开篇提出软件由程序与软件工程两部分构成。程序是能完成特定功能的计算机指令，而软件工程则涉及开发、运营、维护等活动。但在实际开发中，代码质量保障（如单元测试、代码规范）既像是"程序"的延伸，又像是"软件工程"的范畴。

查阅资料： IEEE 对软件工程的定义强调"将系统化、规范化、可量化的方法应用于软件的开发、运行和维护"。也有人认为，一旦涉及多人协作、版本管理、需求分析，就进入了软件工程领域。

提问原因： 我的假设与书中划分存在冲突。在个人小项目中，我往往只写代码、不写文档、不做系统化测试，这算不算"软件"？若一个人独立完成一个完整项目，其"程序"与"软件工程"的比重应如何理解？我困惑的是：这个公式是否暗示"没有软件工程就没有软件"，还是说软件工程是随项目规模而逐步引入的？

---

问题二：结对编程在效率与成本之间的平衡点在哪里？

触发章节： 第4章 两人合作 —— 结对编程（Pair Programming）

上下文： 书中介绍结对编程可以让两人共同完成同一份代码，提高质量、促进知识传递。但直观上，两个人做一个人能做的事，人力成本似乎会翻倍。

查阅资料： 有研究指出结对编程能减少约15%的开发时间、显著降低缺陷率；也有观点认为结对编程更适合复杂逻辑或新手学习阶段，简单重复性工作不一定适合。不同团队对结对编程的采纳程度差异很大。

提问原因： 书中的描述与我的间接经验存在矛盾。我参与过的课程项目大多是分工各自写模块，很少真正"坐在一起写同一段代码"。我困惑的是：在现实中，企业如何决定何时采用结对编程？是否存在明确的适用场景（如复杂算法、核心模块）与不适用场景（如简单CRUD）？成本翻倍带来的收益在何种项目规模下才能被接受？

---

问题三：敏捷流程中的"拥抱变化"与"需求冻结"是否矛盾？

触发章节： 第6章 敏捷流程 —— 敏捷宣言与原则

上下文： 敏捷强调欢迎需求变更、快速响应变化；同时在实际项目中，往往需要在某一阶段"冻结需求"以推进开发。书中也提到敏捷团队需要与客户紧密沟通、迭代交付。

查阅资料： 敏捷宣言主张"响应变化胜过遵循计划"；Scrum 中每个 Sprint 会锁定本迭代范围，但在 Sprint 之间可调整 backlog。有实践者认为"拥抱变化"不等于无限变化，而是通过短周期迭代把变化控制在可管理范围内。

提问原因： 对书中的推理过程有疑问。若每个迭代都允许需求变更，项目方向会不会不断摇摆？若需求冻结，是否又违背了敏捷精神？我困惑的是：书中所说的"拥抱变化"在操作层面到底如何落地？是否有明确的规则来区分"可接受的变化"与"应拒绝的变化"？

---

问题四：单元测试的覆盖率目标应如何设定？

触发章节： 第2章 个人技术和流程 —— 单元测试

上下文： 书中强调单元测试的重要性，能减少调试工作、提升代码变更信心。但未明确说明单元测试覆盖率应达到多少才算"合格"。

查阅资料： 业界有"80%覆盖率"的说法，也有观点认为盲目追求覆盖率会导致无意义的测试、忽视关键路径。Google 的测试金字塔强调不同类型测试的比例，而非单一覆盖率数字。Martin Fowler 等人指出，覆盖率高低与代码质量并无简单线性关系。

提问原因： 术语与标准上的困惑。书中提到单元测试的价值，但没有给出可操作的量化指标。在实际项目中，若团队要求"覆盖率必须达到 X%"，这个 X 应如何科学地确定？是否应区分核心模块与边缘模块的覆盖率要求？我希望能获得更具体的实践指导。

---

问题五：软件工程师的"成长阶梯"在不同规模公司是否通用？

触发章节： 第3章 软件工程师的成长 —— 个人能力衡量、职业发展

上下文： 书中描述了软件工程师的成长路径、能力衡量方式（如技能的反面、成长的阶梯等概念）。这些内容多来自大厂（如微软）的经验。

查阅资料： 大厂通常有明确的职级体系（P6、P7、T3、T4 等）；初创公司或中小企业的工程师可能一人身兼多职，职级划分较模糊。不同公司对"高级工程师""技术专家"的定义差异很大。

提问原因： 书中的描述与我的经验存在差异。在中小公司或学术实验室，工程师可能既写代码又做需求、既管项目又管运维，很难严格对应书中的"阶梯"。我困惑的是：书中给出的成长模型是否主要适用于大厂？对于在中小团队工作的工程师，应如何借鉴和调整这些理论？是否存在更普适的成长框架？

---

小结

以上五个问题分别涉及：概念边界（问题一）、实践成本与收益（问题二）、方法论的内在张力（问题三）、量化指标（问题四）、理论适用性（问题五）。期待在后续精读与实践中有更深入的理解。