《构建之法》的阅读和提问

《构建之法》的阅读和提问

个人阅读作业

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	个人作业：阅读和提问
我在这个课程的目标是	希望能更好地走进真实的软件工程开发
这个作业在哪个具体方面帮助我实现目标	对软件工程有更深的认识，锻炼快速阅读与批判性思考

阅读提问

问题一：在“习中学”的实践中，该如何把握项目进度与学习深度的平衡？

学习科学大量研究表明，成人的最佳学习方式并非独自练习，而是在情境中学习。有效学习是进入相关情景，找到自己的【学习共同体】，然后学习者刚开始围绕重要成员转，做一些外围的工作，随着技能增长，进入学习共同体圈子的核心，逐步做更重要的工作，最终成为专家。

——第一章 习而学的软件工程教育 - 怎么教工程类的专业？

我觉得这样的学习方式是很好的，事实上现在的研究生教育，业界的实习与医生的规培等都是如此。但现在我的问题是，在我们当下的学习阶段，我们完成学业任务可能会运用到大量知识或技术栈，而我们有些时候借助AI能完成某些需求但我们又不一定能完全理解或掌握一些细节，导致我们只是完成了任务，而有很多东西也许过一段时间就完全印象不深了。所以，我们该如何推进项目时，更好地真正沉淀一些学习的东西，让我们以后也能很好地复用之前的经验？

对此，我认为做好一些必要的高价值的资料整理与博客记录是必要的，进而我们可以搭建自己的知识能力库，这对未来我们工作或研究应该都是有益的。如果这个知识库能更结构化且加入AI Agent，我想或许能更好地赋能我们的学习与进步。

另外，借助 AI 虽然能快速实现功能，但往往是在‘黑盒’状态下运行。我想请问，在软件工程的快速迭代中，是否应当建立一种‘分层沉淀机制’？即哪些核心逻辑（如算法、架构）必须‘拆解黑盒’去掌握，哪些辅助功能（如排版、简单脚本）可以止步于‘会用即可’？我们该如何建立这套筛选标准，以防陷入‘表面繁荣’的知识空洞？

问题二：敏捷开发中的“每日站会”如何避免演变成形式主义，如何高效执行？

I also recommended eliminating all of the development artifacts – like design documents… Scrum relies on high-bandwidth, face-to-face communication and teamwork; cubicles and unneeded artifacts promote isolation and misunderstandings.

—— Ken Schwaber [Agile Project Management With Scrum, Page 103]

软件开发流程有好多种, 我们怎么衡量一个开发流程是否对当前的项目/团队合适？ 我觉得Scrum/Sprint 能成功实施的关键在于 ScrumMaster。

Scrum对团队的要求很简单：self-managing， self-organizing， cross-functional， 但是这很难做到。如果你的团队很弱, 那么强行把Scrum （或者其它高级方法）套在上面也没有用, 也许还会适得其反，往往需要多次Sprint 才能让Scrum 走上正轨。

——第四章 Scrum/Sprint

简而言之，“每日站会（Daily Stand-up）”是敏捷开发的核心仪式，要求成员汇报：昨天做了什么，今天打算做什么，遇到了什么困难。但是，无论是现有的小组合作或者是科研例会，站会往往会变成组长/导师催进度的工具，而大家聚在一起讨论的效率也比较低，甚至可能出现故意夸大琐碎工作的难度，或者对长期复杂问题一直置之不理。

Ken Schwaber强调一定要大家面对面的沟通，但我们现在时间紧任务重，大家也不好协调时间。而且我自觉自己也不是很厉害，感觉要做到“self-managing， self-organizing， cross-functional”还是很有挑战，这就意味着每个团队成员都要努力完成整个项目，而不止步于自己的工作，需要共同更紧密地合作努力。所以我不知道对于这次软件工程大项目，我们该如何最大限度地应用Scrum，使大家减少不必要的沟通成本又有条不紊地推进项目执行。我记得影视飓风推行的是共享文档式的管理，每次组会都是建立在大家已写好自己工作量，已看完大家工作进度的基础上进行部分问题的讨论，这样可能更高效，或许这学期结束后我会有更深刻的体会吧。

问题三：在“画扇面”式的宏大愿景与 NABCD 模型之间，如何界定“合理的过度设计”？

作者在第6章和第9章提到，要避免“画扇面”（不切实际的目标），并推荐使用 NABCD（Need, Approach, Benefit, Competitors,Delivery/Data）模型来提出项目建议。

但在软件工程历史上，很多伟大的产品最初都是因为“过度设计”或“技术超前”才具备了后来抗衡对手的护城河。例如，早期的 Unix 或 Git，其底层设计的抽象程度远超当时普通用户的需求。

我认可“以用户需求为中心”的实用主义，但如果一切创新都严格遵循 NABCD 中当前的“Need”和“Benefit”，那么我们是否还有对创新技术与前瞻视野的渴求？如果我们总是想着现在，想着盈利，我们是否还能更多地为长远考虑，是否还能坚持”为用户好“而不只是”让用户上头或付费“？在软件工程的“工程属性”（解决问题）与“艺术属性”（创造可能）之间，边界到底在哪里？

问题四：在 AI 辅助编程普及的今天，该如何衡量工作量？

比资历? 大锅饭? 比效率? 背靠背评比? 比不犯错误? 如何区别对待?......

——第10章 绩效管理

在讲义第10章的软件项目的管理中，作者探讨了绩效管理，并提出了“代码量和树叶量”的辩证关系。作者指出，正如不能通过树叶的数量来评价一棵树的价值，也不能简单地用代码行数来考核程序员。

而现在大家已经流行vibe coding，这样再看代码量可能就更不值得参考了。并且AI生成的代码虽然量大，但往往伴随着冗余、安全漏洞或细微的逻辑错误。这意味着，产出的代码行数越多，团队后续进行代码复审（Code Review）和维护的压力反而越大。

书中的观点是“不要迷信代码量”，但在实际的管理实践中，很多团队仍然需要一些可量化的硬指标来衡量成员的投入程度。我们该如何寻找像“解决问题的复杂度和重要程度“这种更难量化、但更接近真实的指标？

问题五：当 AI 抹平了代码实现的门槛，什么才是好的软件工程师？

在第3章的软件工程师的成长中，作者通过 PSP 和各种技能评价指标，将工程师的成长描述为一个从“初学者”到“大师”的过程，强调了基本功的重要性。同时，在讲义第5章中提到“软件开发不是闭卷考试”，鼓励利用工具。

过去，一个牛人是能快速写出复杂逻辑的人。但现在，AI 也能做到。那么，“软件工程师的核心竞争力”是否从“编写代码的能力”转变为“对代码质量的审美能力”和“对复杂系统的纠错能力”？书中关于“技能的反面”这一节，是否需要加入“对工具的盲目依赖”这一项？