现代软件工程：一个学期之后，我对“做软件”这件事的真实理解

现代软件工程：一个学期之后，我对“做软件”这件事的真实理解

个人博客一： https://www.cnblogs.com/BingzhengYan/p/19131278

学期刚开始写第一篇博客的时候，我对“现代软件工程”这门课其实是有点困惑的。
一方面，我已经写过不少代码，也做过课程项目；另一方面，软件工程这个词在我脑子里一直是偏抽象的概念，像流程、规范、文档、协作，但这些东西到底会不会真的影响“把软件做出来”，我当时并不确定。

所以学期初提出的问题，本质上都指向同一个困惑：
这门课，究竟会不会只是把“写代码”换一种更复杂的说法？

一个学期下来，我可以很确定地说：它并不是。
而且，它真正教会我的，恰恰是那些一开始我觉得“没那么重要”的东西。

---

一、从“我能不能写出来”，到“这个东西值不值得现在写”

在项目真正开始之前，我对软件开发的理解非常直接：需求明确 → 写代码 → 完成功能。
但在 Alpha 阶段推进过程中，我第一次强烈地感受到，工程中的核心问题往往发生在写代码之前。

例如：

• 这个功能是不是用户真正需要的？
• 如果时间不够，哪些功能可以砍，哪些不能？
• 当前阶段追求“完整”还是“可验证”？

这些问题在课堂上并没有一个标准答案，但在项目中却会不断逼你表态。
一旦选择了方向，后面的实现就会被这个选择锁死。

我开始意识到，软件工程并不是教你如何避免错误，而是教你在不可避免要犯错的情况下，尽量让错误的代价更小。

---

二、团队合作：不是分工，而是持续的对齐

学期初我对团队合作的理解，其实很简单：
大家分好模块，各自完成，再合起来。

但真正做下来才发现，问题从来不在“谁写哪一块”，而在于：

• 对需求理解是否一致
• 对完成标准是否一致
• 对进度预期是否一致

哪怕是同一个功能，不同人脑子里的“完成”也可能完全不一样。

博客、Issue、阶段展示这些看似“额外工作”的东西，在一开始我其实是有些抗拒的。但慢慢地我发现，它们的真正作用不是给老师看，而是​逼迫团队成员把隐性的理解显性化。

当问题被写出来、被公开之后，就不能再靠“差不多”来混过去了。

---

三、有些问题没有被解决，但我不再害怕它们

这个学期也让我意识到：
并不是所有问题都应该、或者能够在一个项目里解决。

比如：

• 有些技术选型明知道不完美，但必须先往前走
• 有些沟通问题并不是靠一次讨论就能消失
• 有些个人能力短板，需要长期积累，而不是临时补救

以前我会因为这些“不完美”而感到焦虑，现在更多的是一种接受：
工程本身就是在限制条件下做选择，而不是追求理想解。

这种心态的变化，对我来说是一个很重要的成长。

---

四、AI 工具的出现，并没有让工程变简单

在课程项目中，我也大量使用了 AI 工具。
它们确实能帮我更快写出代码、理解接口、查资料，但并没有让我觉得软件工程变轻松了。

相反，它让我更清楚地意识到：

• AI 很擅长“局部正确”，但不擅长“整体正确”
• 如果我自己对需求和架构不清楚，AI 只会放大这种混乱
• 判断“这个结果能不能用”，依然是人的责任

这让我开始重新思考工程师在 AI 时代的角色：
不再只是实现者，而是决策者和校验者。

---

五、这门课的教学方式，为什么让我印象深刻

老师在学期初介绍 NCL 理想教学环境时，我其实并没有太多直观感受。
但当课程逐步展开，我才意识到这些设计背后的用意。

• 持续博客让我无法只在期末“总结一次”
• 自主组队和项目选择，把风险和自由同时交到学生手里
• Alpha 后允许人员调整，让团队问题真实暴露
• 公开展示和同伴反馈，让比较和反思变得不可回避

这门课并不追求“舒服”，甚至在很多时候是有压力的。
但正是这种压力，让我感受到它更接近真实的软件工程环境。

---

六、一个学期之后，我最大的变化

如果一定要总结这个学期带给我的改变，我会说不是技术上的，而是认知上的：

• 我开始习惯在写代码前反复问“为什么”
• 对团队协作有了更现实的预期
• 面对不确定性时不再急着找标准答案
• 更能接受工程中的妥协和不完美

我依然不是一个成熟的软件工程师，但我已经不再把“软件工程”理解成一个空洞的词。

---

结尾

这门《现代软件工程》课程并没有给我一条清晰的“成功路径”，
但它让我真实地体验了软件工程的复杂、混乱与现实。

和学期初相比，我并没有变得更自信，
但我更清楚自己在做什么、为什么这么做，以及还缺什么。

对我来说，这已经是一门非常有价值的课程。