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

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

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	理解现代软件工程中的核心概念，学会把书本中的方法与真实开发环境联系起来思考，而不是只停留在术语记忆层面。
这个作业在哪个具体方面帮助我实现目标	这次作业要求我在阅读中主动提出问题、分析背景、寻找证据并说明困惑来源。它训练的不是摘抄能力，而是把“看懂内容”进一步转化为“形成判断和提问”的能力。

---

1. AI 复审能不能替代同伴复审？

第4章 4.4 节讲代码复审，书里提到自我复审、同伴复审、团队复审，并把同伴复审看作最基本的方式。这一点让我有些犹豫。
现在写代码时，我很多时候不是先找同学看，而是先让 AI 看。它能指出明显的坏味道、边界条件、重复代码，也能帮我补测试。就“第一轮筛错”来说，它已经很好用了。
所以我想问：在大模型时代，同伴复审还是最基本的吗？会不会很多场景里，AI 复审加自我复审已经够了？

我觉得书里的内容有些过时了，技术条件进步了。以前“多一双眼睛”主要靠同伴，现在可以利用 AI。但我也不敢轻易下结论。因为 AI 能看代码，却不一定知道团队约定、业务背景，也无法承担责任。这样看，同伴复审的价值或许仅仅在于承担责任，为代码指令背书。

---

2. 结对编程在今天还有多大意义？

第4章 4.5 节讲结对编程。书里强调，两个人一起写代码，不只是提高质量，也是在共享知识、减少缺陷、互相监督。
但今天很多时候，一个人加 AI 其实也很像在“结对”。我写代码时会让 AI 解释需求、补全函数、检查错误、给备选方案。它反应很快，也没有磨合成本。
所以我会问：如果已经有 AI 参与，传统的两人结对编程还有多大意义？AI 结对能不能覆盖它的大部分价值？

我觉得 AI 确实替代了一部分事情，尤其是查资料、补样板代码、做即时反馈。 结对编程，除了相互鼓励、陪伴的情绪价值，AI难以替代，其余部分似乎可以代替。

---

3. 小项目也要严格做个人软件流程吗？

第2章讲个人技术和流程，提到单元测试、回归测试、效能分析，还有 PSP 这类记录和改进方法。书里的意思我能理解：开发需要专业化，使用专门的方法，来提高开放的水平。
但我读到这里时想到的是，绝大多数小项目，开放时间较短， 这时如果严格记录时间、缺陷、返工次数、估算误差，真的划算吗？
所以我的问题是：对学生项目或小项目来说，严格的个人软件流程，收益真的大于成本吗？
据我所知，GitHub上许多开源的小项目（几万行以内），没有任何测试样例，甚至代码注释都没有。
换句话说，我想追问的是：这些软件工程方法/流程，适用于多大规模的项目？或者适用于什么项目？

---

4. 小团队什么时候该正式分工？

第5章讲团队和流程，强调团队不能只是几个人凑在一起，还要有角色和结构。这个观点我认同，但我马上想到一个现实问题：小团队到底什么时候需要正式分工？
我见过两种极端。
一种是项目刚开始就设组长、PM、前后端负责人、测试负责人，结果团队很小，角色比工作还多。
另一种是一直不分工，大家都“做一点”，最后接口对不上，进度没人管，出了问题也没人拍板。
所以我想问：小团队什么时候应该从“大家都做一点”转向正式分工？
这题是我读书时感受最强的一题，因为它特别像真实项目里的麻烦。
太早分工，容易流程过重；太晚分工，又容易责任不清。

---

5. 成熟的软件工程模型是不是更适合大团队？

第7章讲实战中的软件工程，也提到像 MSF 这样的成熟模型。读这一章时，我最直接的感觉是：这些方法看起来很完整，但它们可能默认了一个前提——团队够大，角色够清楚，资源也比较充足。

这就让我想到一个问题：这些成熟模型是不是天然更适合大公司或中大型团队，而不一定适合小团队？
原因很简单。
大团队需要更多流程来协调人和模块，文档、评审、角色划分都会更重要。
但小团队节奏快，很多人一人身兼多职，如果机械照搬大团队流程，反而可能拖慢事情。