[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	学习软件工程相关的基础知识，并在实战中运用这些知识
这个作业在哪个具体方面帮助我实现目标	了解软工、学习软件工程相关的基础知识

博客链接：https://www.cnblogs.com/BaconToast/p/19694054

一、AI 时代，软件工程师的“智力”是否仍然一成不变？

在阅读 《构建之法》1.2.1 软件的特殊性 时，书中列举了学者总结的软件开发过程中的五点难题：复杂性、不可见性、易变性、服从性、非连续性。其中第一点描述如下：

书中提到，软件的各个模块之间的依赖关系的数量逐年指数增长，而软件工程师的智力、记忆力在过去的几十年都没有大的提高，这导致了软件的复杂性。

我认为此观点在当今乃至未来已经不再适用。如今 AI 高速发展，图像识别模型努力模仿人类视觉，语言模型达到超越常人水平的理解和推理能力，这些由芯片、电流组成的人工智能似乎正逐步发展为“硅基生命”的雏形。倘若未来脑科学取得更多突破，进一步指导人工智能的架构设计和迭代，人类在短期内无法随意对自己进行“更新换代”，但人类亲自塑造的人工智能却能实现这个愿望。软件工程师借助人工智能为“第二大脑”，利用人工智能让软件更易读，不就是扩充了自己的智力和记忆力？将一位熟练运用人工智能工具的工程师和十几年前的他自己相比，不就是发生了“人”本身的变化？

解答：AI确实在改变“智力”的定义，但不是替代，而是增强。

在开发《植胜僵场》的过程中，我们团队确实用上了AI编程工具。但真正让我感受深刻的，不是AI帮我们写了多少行代码，而是我们如何利用它来管理复杂性。

我们的项目有TypeScript、Phaser、Vite、Electron这一整套技术栈，有卡牌、敌人、事件、商店等多个子系统。如果全靠人脑去记每个模块的接口、每种状态的变化，确实会像书里说的那样——超出常人智力的承受范围。

但我们做对了一件事：把游戏的核心内容做成了数据驱动。卡牌、敌人、事件、商店商品都集中在src/data/目录下，新增内容时不用大规模修改场景逻辑。这样一来，复杂的东西被“外包”给了数据结构和配置文件，人的大脑只需要理解抽象的规则，而不是记忆海量的细节。

AI工具在这个过程中帮我们更快地写出这些数据、更高效地调试逻辑。但真正降低复杂性的，是软件工程本身的方法论——分层、解耦、数据驱动。AI是放大镜，不是替代品。

二、Tab 还是 Space？

在阅读 《构建之法》4.2.1 缩进 时，书中描述如下：

书中提到 Tab 键在不同情况下会显示不同的长度，对此我表示赞成。回忆起在大二下学期学习操作系统时，使用课程组提供的跳板机编写代码，缩进是 8 个空格，让习惯了 4 个空格的我非常难受。

但我不赞成使用 4 个空格替代 Tab 键，有以下几点理由：

• Tab 键只需敲一次键盘，空格需要敲 4 次，很麻烦，有时漏敲了变成 3 个空格更麻烦。
• 大多数现代 IDE 例如 vscode 和 idea 都会智能缩进，使用 Tab 更切合这些软件的设置。
• Tab 可以通过设置自定义宽度。

解答：这个问题根本不重要，重要的是一致性。

经历了《植胜僵场》的团队开发后，我最大的感受是：Tab还是Space的争论，在真实的协作面前显得很幼稚。

我们团队5个人，有人用VSCode，有人用WebStorm，有人习惯Tab，有人习惯空格。如果每个人都坚持自己的习惯，代码提交到仓库里就会乱七八糟——同一份文件里缩进忽大忽小，diff的时候满屏都是空白字符的改动。

最终我们做的事情很简单：在项目里配置了.editorconfig和格式化工具，大家各自IDE的保存动作会自动把缩进统一成我们约定的规则。你按Tab也好，按空格也罢，最后提交的代码都是一样的。

书里说“4个空格”是一个具体建议，但我觉得它的精髓不是“4”这个数字，而是“团队要有一致的规范” 。真正的专业不是纠结于按哪个键，而是愿意为了团队协作放弃个人的小习惯。

三、AI 编程助手普及的今天，传统的“结对编程”是否还有必要？

在阅读 《构建之法》4.5.2 为什么要结对编程 时，书中对结对编程给予了很高的评价：

书中提到，在结对编程模式下，一对程序员肩并肩、平等地互为“领航员”和“驾驶员”。书中认为这种模式能提供不间断的代码审查，极大提高代码质量，并促进团队知识传递。

但我对这种纯人类之间的结对编程在当下的普适性和效率表示怀疑，尤其是在学生团队中。

• 首先，结对编程对两人的水平差异有严格要求。在实际的软工课组队中，如果两人代码能力悬殊，往往会演变成“一人熬夜写代码，一人想帮忙又帮不上”的“搭便车”现象，不仅没有起到审查作用，反而浪费了人力资源。
• 其次，随着 GitHub Copilot、Cursor 等 AI 编程工具的全面普及，AI 实际上已经完美胜任了“领航员”甚至部分“驾驶员”的角色。AI 可以在我输入代码的瞬间完成逻辑补全、边界条件审查和漏洞检测。既然我们可以实现“Human-AI”的高效结对，且不需要考虑沟通成本和情绪价值，那么传统这种耗时、对性格与能力匹配度要求极高的“Human-Human”结对编程，是否已经成为一种应当被淘汰的低效开发仪式？

解答：结对编程的价值不在于“审查代码”，而在于“对齐认知”。

在《植胜僵场》的开发中，我们确实没有严格意义上“肩并肩坐在一台电脑前”的结对编程。但我们做过很多次两个人一起开会讨论设计方案、一起Review PR、一起Debug。

这些场景让我意识到：人类结对和AI辅助做的事情完全不同。

AI可以在我打字的时候补全代码、提示语法错误、甚至写出一个函数的实现——这确实像是一个“领航员”的角色。但AI不理解我们为什么要做这个功能，不知道这个卡牌的设计意图是什么，无法判断“这个Boss的数值应该调高还是调低才有趣” 。

当我们两个开发者坐在一起讨论一段代码时，我们交换的是上下文——为什么要这样设计、之前踩过什么坑、接下来打算怎么改。这些东西AI给不了。

所以我的结论是：AI编程助手不是取代结对编程，而是把结对编程从“语法审查”解放出来，让它回归到“设计讨论”的本质。以前结对可能有一半时间在查语法、找拼写错误，现在这些事AI帮你做了，两个人可以花更多时间聊真正的设计问题。

四、敏捷流程中的“每日例会”在学生团队中是否容易变成形式主义？

在阅读 《构建之法》6.1 敏捷的流程简介 时，书中介绍了敏捷开发中非常关键的一个环节：

书中强调，团队每天要抽出时间面对面开会，每个人依次汇报：昨天做了什么、今天打算做什么、遇到了什么困难。书中认为这能让团队成员了解彼此进度，及时发现问题。

我认为这个理想化的敏捷仪式在大学生团队（乃至部分采取远程办公的现代企业）中行不通。大学生的时间是高度碎片化的，每个人有不同的课表、实验和活动。强行要求每天凑在一起开会，往往会演变成一种负担。很多时候为了完成软工课的任务，大家只是机械地在群里发几句废话，或者为了应付助教而在例会时摆拍，立会彻底流于形式。

此外，在现代工程协作中，像 GitLab/GitHub 的看板、飞书/钉钉的自动化进度追踪，已经能够实现彻底的“异步协同”。我们完全可以通过看代码仓库的 Commit 记录和 Issue 状态来了解进度。强行遵守这种僵化的流程，是不是反而违背了“个体和互动高于流程和工具”的核心价值观？

解答：例会的形式可以变，但“同步”这件事不能省。

在《植胜僵场》的开发过程中，我们确实没有做到每天面对面开会——大家课表不一样，凑齐6个人太难了。

但我们做了几件事来代替：

• 每周固定的线下同步会，每次30-60分钟，大家坐在一起过进度、讨论阻塞问题；
• 用飞书/钉钉的看板管理任务状态，谁做了什么、卡在哪里一目了然；
• 重要的设计决策在群里讨论，有结论后更新到文档里。

书里说的每日立会，本质上是强制团队保持信息同步。在学生团队里，强制每天见面确实不现实，但“信息同步”这个需求本身并没有消失。

我们每周的线下会反而比每天的线上会更有效——因为大家真的坐在一起了，注意力集中，能深入讨论问题。那些“我昨天做了啥、今天要做啥、遇到了啥问题”的流水账，我们用看板代替了；线下会的时间全部用来解决真正需要讨论的问题。

所以我觉得，不是每日例会这个制度有问题，而是它的形式需要因地制宜。在学生团队里，一周一次高质量的面同步，可能比每天在群里发一句“我今天写了两个卡牌”更有价值。

五、在软工课中 PM 是否变得无用？

在阅读 《构建之法》9.3 PM 做开发和测试之外的所有事情 时，书中详细定义了微软模式下的 PM 的职责：

书中指出，PM 负责做商业分析、收集需求、制定计划、协调资源以及撰写文档，而把写代码和测试的专业工作留给开发和测试人员。书中的理念是：开发人员应当专注于实现，PM 则是团队的润滑剂和对外的接口。

但在软工课这样的小型学生团队实践中，我对设立“专职 PM”这一角色的合理性存疑。在学生项目中，整个软件的规模通常不需要极为复杂的商业调研，真正的核心难点往往在于技术实现。如果团队中有一名同学完全按照书中所述只做 PM 不写代码，在项目初期画完原型图、写完需求文档后，中期极易陷入“无事可做”的状态；但在最终项目答辩时，PM 往往因为负责制作 PPT 和主讲，在评委面前获得了最多的曝光度。

这会导致一个极大的不公平：写核心架构的程序员可能拿不到最高分，而依靠“沟通和文档”的专职 PM 却能轻松名列前茅。在无法做到像成熟企业那样拥有完善绩效考核机制的学生团队里，如何界定 PM 的真实工作量？在 5 人的小型学生团队里，由核心开发人员兼任 PM，是不是比设立一个不碰代码的纯 PM 更能服众、更符合实际？

解答：PM的工作量比我想象的大得多，而且不写代码不代表不干活。

在《植胜僵场》的项目中，我们团队有明确的PM角色。我一开始也觉得“PM不就是画画原型图、写写文档、最后讲个PPT吗”，但实际经历下来，完全不是这么回事。

这些东西确实不写代码，但它们让写代码的人能安心写代码。如果没有PM去整理需求、去和老师对接、去写文档、去安排发布，开发人员就得自己花时间做这些事——而这些事往往比写代码更耗精力。

关于“公平”的问题，我们的做法是：PM也参与核心代码的review和部分简单功能的实现，不是完全脱离代码。在最终的评分中，大家根据各自的贡献来评定，PM的工作量是可见的——文档写了多少、例会组织了多少次、发布做了几轮，这些都是可以量化的。

所以我的结论是：在学生团队里，专职PM是必要的，但“专职”不等于“不碰代码” 。PM可以写一些辅助脚本、做做测试、修修简单bug，保持对代码的感知。而真正核心的架构设计和复杂功能，交给技术能力更强的同学。分工不同，但贡献同等重要。

学到了什么知识点

一、需求阶段：NABCD模型

• 学到的知识点：需求不只是“我要做什么”，而是用NABCD（Need需求, Approach手段, Benefit好处, Competition竞争, Delivery交付）去论证“为什么做”和“怎么做得到”。其中最容易忽略的是Approach（手段） 必须基于团队技术栈的现实。
• 项目经历与心得：初期大家热血沸腾，想加入联机对战、地图编辑器等炫酷功能。但我们运用NABCD严格过了一遍，发现以Phaser + TypeScript + Electron的技术栈和6人的规模，实现联机（手段Approach）风险极高。我们果断砍掉，将核心需求收敛为“单机卡牌肉鸽 + 无尽生存模式”。这次经历让我明白：需求阶段不是头脑风暴，而是用模型做减法，把资源集中到最有价值且技术可行的核心循环（种植物、抽卡、打僵尸）上。

二、设计阶段：数据驱动架构

• 学到的知识点：好的设计追求高内聚、低耦合，而实现这一点的实用手段是数据驱动——将实体的属性（数值、描述、资源路径）抽离到配置文件中，程序逻辑只负责读取和处理这些数据。
• 项目经历与心得：我们将所有卡牌、敌人、事件都集中到了src/data/目录下的纯数据文件（TS对象/JSON）中，主逻辑只依赖数据接口。重构后的两周里，策划同学都能直接修改JSON调平衡性，程序员完全不用动核心代码。这个知识点让我真正体会到：设计的本质是为未来的变化留出接口，而不是把代码写死。

三、实现阶段：编码规范与Git协作流程

• 学到的知识点：实现阶段的核心不是“写出来”，而是“可读、可合并、可回溯”。通过制定分支策略（如main主分支稳定版，dev开发分支，feature/xxx特性分支）和自动化格式工具（ESLint/Prettier + .editorconfig）来保证代码一致性。
• 项目经历与心得：初期大家各自开分支写，合并时出现了大量冲突，有一次光是解决缩进和行尾符冲突就花了整个下午。之后我们严格执行“每开发一个功能，必须从dev切新分支，完成后提PR（Pull Request），至少一人Review后才能合并”，并配置了保存自动格式化。从此冲突率直线下降。

四、测试阶段：回归测试

• 学到的知识点：测试不只是找Bug，尤其是回归测试，当新增一个卡牌或修改一项数值时，必须重新验证原有核心流程是否仍然正常工作。

五、发布阶段：构建与环境一致性

• 学到的知识点：发布不单单是“打包上传”，而是要保证开发环境、测试环境和生产环境的一致性。构建工具的配置、Electron的跨平台打包参数，任何一个环境差异都可能导致发布失败。

六、维护阶段：文档同步与知识沉淀

• 学到的知识点：维护阶段的敌人不是代码，而是过时的文档和模糊的设计意图。当需求变动或Bug修复后，必须同步更新技术规格说明书和注释，否则几个月后连自己都看不懂当初为什么这样写。
• 项目经历与心得：PM最初写了很详细的需求文档，但开发中期为了赶进度，很多接口变动只口头通知，没有更新文档。结果后期有另一位同学想修改一段Boss AI逻辑时，对着过时的文档和实际的代码完全是两张皮，花费了大量时间逆向工程。

总结

项目形态	核心挑战	我的理解与心得
个人项目	自律与基本功	一个人写代码时，最大的敌人是懒惰（不规范命名、不写注释、不测试）。这时候“知识点”是孤立的，学会了就忘，因为没有协作的压力。
结对编程	沟通与思维对齐	两个人写同一段逻辑时，必须把隐性的思路“外显”出来。我明白了接口约定比代码本身更重要——参数名、返回值结构一旦定好，两人各写各的模块才不会互相踩脚。
团队项目	分工与系统整合	当人数达到6人、代码达到几万行时，任何个人能力都显得渺小。真正起作用的是流程规范、数据驱动架构、和定期同步机制。软件工程的知识点从来不是“背”会的，而是在某次惨烈的合并冲突、某次发布崩溃、某次PM催进度时，痛彻心扉地“悟”出来的。