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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习软件工程实践中的方法论，提升团队协作能力，最终实现一个完善的软件
这个作业在哪个具体方面帮助我实现目标	通读一遍《构建之法》，构建基本软件工程框架，提高批判思维以及对于软件开发过程的理解

问题 1：代码复审与结对编程的互补性

章节： 讲义第三节结对编程中的结对编程与代码复审对比

引用内容：

"结对编程是持续复审，传统复审存在延迟和覆盖面问题。"

疑问：

若已采用结对编程，是否仍需定期组织团队级代码复审？两者是否存在重复？

资料与经验：

Google 的代码审查实践表明，即使有结对编程，仍需独立审查。
以及我在参与项目时，即使你在项目中写得很仔细，每一个都进行了详细测试，但仍需进行团队一起的审查，这两者会有一些交叉，进而导致资源浪费。

矛盾点：

教材强调结对编程的实时性优势，但未讨论其与团队复审的协同关系。实践中如何平衡两者的资源投入？当采用结对编程后，整体已经比较繁琐了，虽然团队审查可以加入不同人员的眼光和经验，但并没有具体的指标去评判两者如果协调。

---

问题 2：进行单元测试的人员

章节： 讲义第二节单元测试

引用内容：

"单元测试必须由最熟悉代码的人（程序的作者）来写。"

疑问：

这句话感觉有点绝对了，虽然最熟悉代码的人是程序作者，但是可以进行黑盒测试，这时候数据点更为重要。

资料与经验：

在进行OO等课程时，我们也要书写单元测试，此时我认为最难的是构造出比较边界的数据点，代码修复的过程其实有了强大的调试工具，跟着一步一步进行即可，所以在进行单元测试时，我觉得应该通过黑盒测试的方式，让擅长人工构造数据点的人员参与进来，反馈给程序作者，且这种数据的捏造很难通过自动化来实现。

---

问题 3：SCRUM中的三步半问题

章节： 讲义第四节SCRUM部分的第三步半

引用内容：

"谁来做这第三步半呢? 程序员写完功能的时候, 我们感觉好像项目完成了 80%, 殊不知后面的20% 往往要花费80% 的时间, Sprint/Scrum 没有明确表明到底 何人/何时/何种优先级 来完成这个20% 的任务。"

疑问：

在SCRUM部分已经很明确提出第三步半的问题，但最后在SCRUM中的处理也只是模棱两可，后续有个博客作为了第三步半应该做什么，作为SCRUM流程图的补充，有没有较为常用的方式去估计这三步半的消耗以及应该怎么样去衡量让谁完成以及是否需要额外增加一个人去完成这部分，因为这部分的内容往往是繁琐且较为基础的，很多时候甚至可以说与核心的技术并不相关，是否会出现人员协调上的问题。

资料与经验：

如讲义中所说，我们很多时候所谓的完成了，只是代码上的写完，甚至基础功能上还有问题，但这时候其实组内人员就会出现一种懈怠感，剩下的这部分工作很容易导致拖延，以前我们完成一个项目时，有时会设置一个专门的人去进行这部分，但这样好像会导致这个人做的工作与其他人比较割裂，对于个人的成长也较小，应该怎么去衡量这部分，总是感觉他的付出与收益不成正比。

---

问题 4：技术可行性评估如何避免过度乐观

章节： 讲义第六节需求中的NABCD的A

引用内容：

"学生称‘懂Java’可能仅通过考试，实际开发能力存疑。"

疑问：

团队如何量化自身技术能力？是否有评估框架（如技术雷达）避免“冒泡排序级团队挑战分布式系统”？

资料与经验：

这个问题不只是在接到项目时所具备的技术，还要涉及学习能力，比如有的技术可以在进行时进行学习，而这种想法往往会导致过度乐观，特别在校园内做项目，此时更容易产生这种想法，最终导致的就是一个团队NABCD的全面崩塌(其中一个因素可能是对于学生最大限度的信任），有没有相应的评价框架可以更加去约束规范这一现象。

---

问题 5：如何评估短期刺激与长期用户体验的冲突

章节： 讲义第七节设计与开发中用户界面与用户体验

引用内容：

"微软学术搜索的家族树动画虽酷，但用户第二次访问时无新信息。"

疑问：

如何通过用户行为数据（如留存率、使用频率）评估短期吸引力与长期价值的平衡？

资料与经验：

一个软件的UI是可以在第一眼吸引到很多用户，包括我自己在玩游戏使用软件时，画风好，UI精美的我一般会有初步的好感，但审美会有疲劳的，新鲜感也会消失，随着使用，可能会面临用户的流失，且当时在这方面进行了投入，占用了很多资源，却达不到实际层面的意义。

---