《现代软件工程》作业1

读《构建之法》后的五个问题

问题一

在第9章9.2.1节“团队知识的四个象限” 和 第11章11.5.2节“工程师的不可替代性”中提到，AI只能处理“显性知识”，而人类工程师的核心优势在于“默会知识”——那些说不清道不明的经验和直觉。但现在的大语言模型（LLM）似乎正在将很多过去靠专家直觉判断的东西，比如推荐更优雅的设计模式或警示一个潜在的性能陷阱，变成了可以被统计和推断的规律。

所以，AI是否已经在掌握过去属于“默会”领域的知识？如果是这样，那未来软件工程师真正不可替代的、更深层次的“默会知识”又会是什么？

问题二

在第17章7.7节中关于“萝卜与白菜”的案例，做事快但质量差的“萝卜”定义为团队的“负债”，而稳扎稳打的“白菜”是“资产”。

但在一个急着验证市场、抢占先机的初创公司里，一个能让产品快速迭代的“萝卜”，即使留下了技术债务，他的价值会不会暂时比“白菜”更高？

问题三

在第11章11.8.1节中关于“构建大师”这个做法，我们有一些困惑：

1. 在现实中，很多构建失败的原因很复杂，责任并不清晰（如并发修改冲突、新代码触发潜伏旧Bug）。在这种情况下，将“构建大师”的帽子扣给某一个人是不是不太公平，而且容易引发团队内耗？
2. 被指定的“构建大师”会不会因为压力太大，倾向于做一个临时的“快修”来尽快恢复构建，而不是花时间去找到并解决问题的根本原因？
3. 这种带有“惩罚”性质的机制，是否会打击工程师进行大规模重构等高风险、高价值工作的积极性？

问题四

在第5章5.3.6节中对比了MVP（最小可行产品）和MBP（最强最美产品）两种策略，并用iPhone作为MBP成功的例子。

但在今天的市场环境下，技术和需求都变化得太快，竞争非常激烈，打造一个MBP的风险似乎越来越高。

• “惊艳亮相”的MBP策略是否正变得越来越少见，而快速试错的MVP成了绝大多数团队（尤其是初创公司）唯一现实的选择？
• 如果几乎所有团队都只敢走MVP路线，不断做微小的、渐进式的改进，这是否会导致整个行业丧失了创造像iPhone那样、真正具有颠覆性的产品的勇气和能力？

问题五

在第17章17.6节“绩效管理”中，关于IBM经理巴克斯的绩效管理案例，他直接告知员工薪资，而不告知其在团队中的具体排名或等级。

但一个很现实的问题是：在一个团队中，薪资往往是绩效最直接的体现。即便管理者不公布排名，员工们私下通过交流，难道不是能轻易地根据薪资高低，反推出自己和他人在团队中的相对位置吗？

教育模式与师生关系

对于大学现有的教育方式，我认为有一个核心问题在于师生之间缺乏有效的沟通。很多时候，教学更像是老师单方面完成职业任务——照本宣科，缺少情感投入，导致学生感觉不到老师的用心，学习的积极性也因此下降，宁愿选择自学。

当然，我也很幸运地遇到过理想的师生关系。有的老师上课充满激情，认真对待学生的提问，这极大地激发了我们的交流欲望和学习效果。尤其在硕士期间，我的导师“对事不对人”，交流反馈及时且有建设性，每一次交流都让我受益匪浅。这种关系让我即使面对困难，也有信心和底气去解决。

在这门课程中，我非常认同老师提到的 “教练与学员” 的关系。我主动选择这门课，希望能学习和锻炼工程能力。所以我期望老师能将我们的作业视为一个重要的沟通窗口，通过专业的反馈，指导我们前进的方向，帮助我们成长。