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

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15608
我在这个课程的目标是	系统性的学习软件工程的知识，逐步成为一个成熟的软件开发者
这个作业在哪个具体方面帮助我实现目标	初步了解软件工程中各方面的知识，并在阅读教材的过程中锻炼提出有效问题的能力

阅读提问

问题一：如何区分 re-work 是“有价值的探索”还是“低水平的重复劳动”？

在《现代软件工程讲义 2 工程师的能力评估和发展》一章中，作者在讨论如何衡量软件工程师的工作质量时，提到了“返工（re-work）”这个概念。原文如下：

“笔者认为，re- work只是表明在软件开发过程中花费的时间，re- work的多少并不和最终的质量成正比关系。软件开发过程很大程度上是一个探索和实验的过程，不同的re- work能帮助工程师深入了解项目的各个难点，尽早交付原型，找到最优解决方案，等等。因此re- work是有价值的。当然，如果一个程序员为了一个简单的问题而不断地re- work，其工作效率就不是太高- 这可以用时间花费来考虑。”

作者在后文引入了“标准方差”的概念，用Al和Bob的例子说明，除了平均交付时间，交付的稳定性同样是衡量员工能力的重要方面。这为评估“返工”提供了一个潜在视角：如果“返工”是为了探索，它是否导致了交付时间的巨大波动？

根据我的理解，在许多工程管理实践中，无论是传统的KPI还是敏捷开发的 velocity 追踪，都倾向于减少不必要的返工，追求效率。作者的观点让我意识到，完全否定“返工”可能扼杀创新和深度解决问题的过程。

我的困惑在于：我们如何在实际管理中操作这个理念？

如果一个工程师花费大量时间反复修改代码，他可以说这是在进行“有价值的探索”。另一个工程师则可能因为前期思考不周、编码习惯不好而不断“返工”。从结果上看，都是花费了额外的时间和代码修改次数。文中提到的“时间花费”和“交付稳定性（方差）”似乎不足以完全区分这两者。

---

问题二：从“Master/Slave”方案的失败到“Program Manager”模式的成功，这种演变是否真正解决了软件团队沟通的复杂度问题？

在《现代软件工程讲义 5 项目经理 Program Manager》中，作者讲述了微软PM的来历。Charles Simonyi发现随着团队规模扩大，成员间的沟通途径数量呈平方级增长（n*(n-1)/2），导致交流不可持续。他提出了“Master Programmer 和 Slave Programmer”的分层方案：MP负责与外界沟通、写抽象伪代码，SP负责具体实现，这样SP只需和MP交流，试图降低沟通成本。但这个方案失败了，因为“没有人想做Slave Programmer”。随后，Jabe Blumenthal提出了Program Manager(PM)的头衔，PM不写代码，专门负责需求、设计、流程等开发和测试之外的所有事情，从而让开发人员可以专注于编码。

n个成员的团队交流途径总数为 n*(n-1)/2，直观说明了全连通沟通模式的不可持续性。“Master/Slave”方案即使理论上能减少沟通，但“没人愿意做Slave”揭示了人的社会性需求——工程师希望有创造性和平等地位，而不只是执行者。PM的出现正是为了解决“程序员听不懂市场语言”“市场人员不懂技术”的翻译问题，以及处理程序员不愿花时间的杂事。PM承担了与各方沟通并形成清晰设计文档（spec）的职责。

我有两个困惑：

• 沟通复杂度的问题真的被解决了吗？引入PM后，团队结构变成了“开发—PM—其他角色”的星型或树型网络。PM成为了沟通枢纽，他需要与所有开发、测试、市场、老板等角色沟通。那么，PM个人的沟通负担就变得极重，这可能成为新的瓶颈。
• 在现实中，如果PM能力不足，或者团队规模过大，这种模式是否会崩溃？有没有一些量化研究或实践案例，比较不同团队结构（如全连通、分层、PM制）下的沟通效率和项目成功率？

---

问题三：“赢者通吃”式评分规则是否会过度激化学生之间的竞争，反而削弱团队合作和互帮互助的氛围？

在《现代软件工程讲义 0 教学方法 》一章中，作者详细阐述了评分方法。他反对传统的“最好10分，次好9.5，平滑下降”的评分方式，认为这不符合软件行业“赢者通吃”的规律。他提出：完成质量第一档次的学生得满分，第二档次得1/2分，第三档次得1/3分，以此类推。他还写了一个平庸的解法作为基准，比这个基准还差的作业得负分（-1，-2，-3…）。作者解释这样做的理由是：在软件市场，第一名占据50%以上份额，第二名可能只有很少份额，这虽然不公平但很现实；训练中也要体现这一规律，让同学明白差距。

我的困惑在于：这种评分方式是否可能在学生中制造过度的焦虑和对立，反而损害了团队协作的精神？在团队项目中，如果团队成员水平不一，评分如何分配？如果团队整体排名较低，所有成员都得到低分，是否会打击团队士气？

我个人认为，评分体系需要平衡“激励竞争”和“鼓励探索”的关系，而“赢者通吃”可能过于极端。作为一个教学课程，应该让学生有时间积累开发经验，而不是像残酷市场一样直接将能力差的学生“判死刑”。当然平滑给分也难以起到良好的教学作用，因此如何设计一个合理的评分体系是很有挑战性的。

---

问题四：在大语言模型日益强大的今天，传统“做中学”的教学方法是否会面临根本性冲击？如何防止学生滥用AI而失去真正的能力锻炼？

邹欣老师的博客写于2011年，当时AI技术尚未成熟。但《现代软件工程讲义 0 教学方法》一章中多处强调“做中学”、真实项目、及时反馈、严格训练等理念。

上《现代软件工程》 的同学, 都是大三到研一的同学, 应该具备基本的学习能力和开发能力, 软件工程和其他类的工程 (如航天工程, 化学工程) 不一样, 我们每天都可以用到软件工程的产物 (软件), 搭建, 学习一个软件开发平台比航天化工要容易很多 (注: 在自家后院放二踢脚不是航天工程), 相关的学习资料也是非常容易获得。 在这个情况下, 学生们可以在“做”的过程中学习, 这也叫”做中学”. 做了, 有疑问, 再问老师, 问专家, 这样学习的效果会好很多。

这些理念在今天依然重要，但AI的崛起给教学带来了新的挑战和机遇。

我读了这段文字，联想到当前AI工具对编程教育的深刻影响。邹欣老师如果今天写这篇博客，一定会讨论AI。我的困惑是：传统的“做中学”要求学生亲手写代码、亲手调试，这是为了培养扎实的编程能力和问题解决能力。但现在AI可以代劳，学生可能只需要描述需求、调整提示词，就能得到结果。如果学生过度依赖AI，可能会失去对基础概念的理解，成为“提示词工程师”而非真正的软件工程师。如何在教学中平衡AI的使用，既利用其优势，又避免能力退化？作者提出的严格训练、高标准要求是否依然适用？

---

问题五：在敏捷开发日益普及的今天，图形化建模方法（如UML）是否还有其不可替代的价值？

在《现代软件工程讲义 7 分析和设计方法》一章中，作者引用了两位顶级程序员对UML的看法：

在《Coders at Work》这本书里面， Java 架构师，畅销书 《Effective Java》的作者Joshua Bloch 对于“你用过UML 设计工具么?” 的回答是：
“没有。 能把设计画成图，让别人理解当然很好。 但是说实话我真的记不起来哪些模块应该是圆形，哪些是方形。”
谷歌研究院的院长 Peter Norvig被问及同样问题的时候说：
“我从来不喜欢UML类型的工具，如果你不能通过计算机语言表达 (UML 要表达的东西)， 那就是这种语言的弱点。“

随后，作者又引用了UML推动者之一Grady Booch的话：“在UML出现之前和之后，软件项目成功的关键依然是——智慧地使用技术、遵从一个好的软件开发过程、有经验的开发者和适当的技能组合。”这些观点形成了鲜明的对比。

敏捷宣言强调“可工作的软件高于详尽的文档”，这与传统瀑布模型中依赖详细设计文档的做法相冲突。在敏捷团队中，UML图往往被简化为白板上的草图，而非正式的、需要维护的文档。

实际项目中，在许多互联网公司，开发团队更倾向于用代码、测试和简单的架构图来沟通，而较少使用严格的UML图。然而，在涉及复杂系统、分布式架构或需要与外部团队协作时，清晰的架构图（可能不是严格UML）仍然必不可少。

我读了这一段文字产生了困惑：我们花大量时间学习UML和各种图形建模方法，究竟是为了什么？在实际工作中，这些图真的被用上了吗？如果连顶尖开发者都不认可其价值，那么课程教给学生的是否是一种过时的技能？此外，当AI工具能自动从代码生成UML图时，传统的手工建模是否会被淘汰？