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

软工阅读提问：《构建之法》

项目	内容
这个作业属于哪个课程	BUAA 软件工程（2025 春）
这个作业的要求在哪里	作业要求
我在这个课程的目标是	了解、学习软件工程的理论并进行软工实践
这个作业在哪个具体方面帮助我实现目标	通过阅读教材提出问题，激发对软工理论的深入思考，助力理论学习

---

📝 问题 1：一个软件工程师究竟应该做什么？

我在 讲义 1：软件工程概论 中阅读到以下文字：

在成熟的航空工业中，一个飞机发动机从构思到最后运行，不知道要经历过多少人，多少工序，多少流程，多少相关知识的验证。我们无法想象，如果最后某个商用型号的发动机在飞行时发现问题，最初的设计师会自己爬到引擎中敲敲打打，然后钻出来说，“继续飞吧，我搞定了”。然而，在软件行业中，很多软件工程师往往以做这样的事而自豪。

文中认为，一个软件工程师在软件工程中的角色更像是最初的设计师，而不应是动手修修补补的角色。

但在我的实践及认知中，软件工程师往往既是设计师又是工程师，我们不仅要设计软件的功能，还要亲自实现它。而且有些时候，不实践根本没办法验证设计的合理性。

相比航天工程，软件行业更具 短平快 的特征。一个发动机的设计到落地可能需要 数年，而一个软件项目的开发可能仅需 几个月。在这种情况下，一人身兼数职似乎是普遍现象。

🤔 我的疑问

• 软件工程师的职责到底应该是什么？我们应更偏向 设计师 还是 工程师？
• 在实际开发中，一线开发者是否应该更多地关注架构设计，而不是直接实现？
• 软件行业是否真的需要向其他成熟工业领域学习严格的分工，还是说这种“全栈式”工程师模式更符合软件行业的特点？

---

📝 问题 2：PM 需要懂技术细节吗？

我在 讲义 5：项目经理 中阅读到关于 PM（项目经理）的任务和所需能力：

PM 应该具备：

• 学习能力
• 观察理解能力
• 分析管理能力
• 销售能力
• 交流、处理冲突的能力
• 一定的专业能力
• 角色转换的能力
• 自省的能力

从这份能力清单来看，PM 似乎不需要太深的技术背景，而更强调沟通与管理能力。那么，如果一个 PM 完全不了解技术实现，仅靠以上这些能力，是否可以胜任工作？

🤔 我的疑问

• PM 在项目中需要多大程度的技术理解？他们是否需要能 写代码，还是只需要 理解架构？
• 一个情商极高但不懂技术的 PM，和一个情商一般但技术能力强的 PM，哪个更有竞争力？
• 在互联网行业，PM 是否会被更懂技术的角色（如架构师、Tech Lead）所取代？

---

📝 问题 3：程序员和码农（Coder）有什么区别？

我在 顶级程序员的心得 这一节中看到：

程序员 vs. 码农：Peter 认为 Coder 把程序员的工作定义得太狭隘了。就像 IT 民工，翻沙，砌墙。砌墙并不是一个坏工作，但这只是“建筑”这一过程中的一个小部分。

那么，程序员和码农究竟有什么区别呢？

这个问题有一个我个人更关切的版本：
科班出身的程序员，和那些自学或培训出身的程序员，究竟有什么区别？

在大二时，我给自己找到了一个答案：我们能接触到更系统的知识，比如操作系统、计算机体系结构、GPU 内存管理等。而这些内容自学较难深入。

但后来我发现，这个答案并不够充分。因为我自己在操作系统课程中理解得并不透彻，学 GPU 相关的知识也是学了就忘。如果最后的职业选择是后端开发，那是不是意味着科班和培训的差距其实并没有那么大？

🤔 我的疑问

• “码农”与“程序员”的真正区别是什么？ 是否只是对工作的态度，还是体现在能力层面？
• 科班出身的程序员，是否在行业内有更大的竞争优势？ 还是说进入职场后，学历的影响迅速消失？
• 如果最终只是去写业务代码，那在大学花四年学操作系统、编译原理是否值得？

---

📝 问题 4：技术债务（Technical Debt）应该如何权衡？

我在 第 6 章：代码质量与重构 中阅读到 技术债务（Technical Debt） 的概念：

技术债务指的是由于短期利益（如赶进度）而导致的代码质量下降，这些“债务”在未来可能会导致更高的维护成本。

但是，在实际开发中，我们经常会遇到这样的情况：如果不快速推进项目，可能连“未来”都没有。例如，初创公司可能根本无力偿还技术债，甚至不一定能撑到“还债”的那一天。

🤔 我的疑问

• 在现实软件开发中，如何判断何时应该偿还技术债务？
• 是否有可以量化技术债务的指标，例如代码复杂度、维护成本等？
• 在大厂和创业公司，技术债务的管理方式有何不同？

---

📝 问题 5：软件需求分析如何避免“需求蔓延”（Scop Creep）？

我在 第 3 章：需求获取与分析 读到，需求管理的一个挑战是 “需求蔓延”（Scope Creep）：

需求在项目过程中不断增加，导致项目范围失控，进度和成本超出预期。

作者建议用 敏捷开发 和 MVP（最小可行产品） 来控制需求增长。但如果客户或产品经理不断提出新需求，开发团队又该如何应对？

🤔 我的疑问

• 如何判断一个新需求是合理的优化，还是需求蔓延？
• 在敏捷开发中，如何有效管理需求变更？
• 是否有具体的量化指标或决策框架，来帮助评估哪些需求应该接受，哪些应该拒绝？

---

总结
通过阅读《构建之法》，我不仅学习了软件工程理论，也在思考自己对软件行业的理解。这些问题，希望能与大家一起讨论！ 🚀