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

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

项目	内容
这个作业属于哪个课程	2026 春季软件工程
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	了解软件工程的完整流程，在真实协作中学习需求、设计、实现、测试、发布与维护
这个作业在哪个具体方面帮助我实现目标	通过回顾个人项目、结对编程和团队项目，把一学期的实践经验重新整理成自己的认识

---

一、回到学期初的问题

学期初读书时，我提出的问题大多来自直觉。那时我还没有经历完整的软件项目，只是从书上的概念出发，去怀疑这些方法在真实开发中是否有用。一个学期之后，经历了个人项目、结对编程《花见小路》、团队项目 campus，再回头看这些问题，很多答案不是“想明白”的，而是“做项目做到一半被迫明白”的。

问题一：AI 参与开发之后，程序员还需要真正理解代码吗？

学期初我有一个疑问：现在 AI 可以生成代码、解释代码、补全测试，那么程序员是不是只需要会提需求和调提示词？

这个问题在结对项目和团队项目中都有比较直接的答案。结对项目《花见小路》中，我们一开始对 Wasm、AssemblyScript 和游戏规则都不熟悉，AI 确实能帮助我们快速理解代码结构，也能给出 scoreAction、evaluatePosition 这类函数的设计思路。但是到真正调试 T3 决策逻辑时，我发现 AI 给出的代码并不能直接等价于“正确代码”。例如 AssemblyScript 对闭包等语法支持有限，如果只是照搬生成结果，很容易出现能看懂思路但无法通过编译或测试的情况。

团队项目中也类似。我负责的内容包括登录鉴权、个人中心、课表创建与编辑、课表导入、AI 聊天、知识库、POI 详情、学习计划回填等前端模块。AI 可以帮助我生成页面框架、mock API、类型定义和部分逻辑，但最后是否能和后端接口对齐、是否符合项目目录规范、是否会影响其他成员的模块，仍然需要人来判断。

所以现在我的答案是：AI 降低了写代码的体力成本，但没有降低理解代码的责任。越是依赖 AI，越要清楚自己提交的代码在项目中承担什么功能、有哪些边界条件、出了问题该从哪里查。AI 更像是一个很强的实习助手，而不是可以替我承担工程责任的人。

问题二：PSP 这种时间记录真的有用吗？

学期初我对 PSP 的怀疑比较强。我觉得开发本来就会被调试、查资料、沟通打断，如果还要记录每个阶段花了多少时间，会不会反而影响效率？

个人项目和结对项目之后，我对这个问题的看法改变了一部分。结对项目《花见小路》中，我们需要记录计划、开发、测试、报告等不同阶段的耗时。刚开始我觉得这只是为了完成作业，但到后面复盘时才发现，如果没有这些记录，很难说清楚到底是规则理解花了时间，还是编码花了时间，还是测试和调试花了时间。

它的价值不在于“精确到每一分钟”，而在于让自己知道时间主要消耗在哪里。比如这次结对项目中，真正耗时的不只是写代码，而是理解题目规则、讨论策略、调整算法和处理 AssemblyScript 限制。没有记录时，我可能会简单地认为“代码写得慢”；有记录之后，才能意识到瓶颈其实在需求理解和设计讨论上。

因此，我现在认为 PSP 的完整表格形式不一定每次都适合，但它背后的思想是有用的：只有知道过去的时间怎么花掉，下一次才可能做出更准确的估算。

问题三：结对编程会不会降低效率？

学期初我对结对编程也有疑问。两个人一起写一份代码，听起来像是把一个人的工作变成两个人做，效率似乎变低了。

做完《花见小路》之后，我觉得这个问题不能简单地用“快”或“慢”回答。单纯从敲代码速度看，结对编程可能确实没有一个人闷头写快。但它减少了很多后期返工。我们在 T3 决策逻辑优化时，经常需要一方提出策略，另一方追问这个策略为什么合理、在什么边界情况下会失效。这个过程会让很多原本藏在脑子里的默认假设暴露出来。

尤其是在 scoreAction 和 evaluatePosition 这类函数设计上，如果一个人写，可能会顺着自己的想法一直写下去；但两个人讨论时，另一方会从可读性、可维护性、测试便利性等角度提出问题。这种“边写边审”的效果，其实就是 Code Review 的提前发生。

所以现在我认为，结对编程牺牲了一部分局部编码速度，但换来了更早的设计讨论和更少的理解偏差。它不一定适合所有任务，但适合规则复杂、设计不确定、需要共同理解核心逻辑的任务。

问题四：测试是不是可以等功能做完之后再补？

学期初我对测试的理解比较浅，觉得只要最后能跑通，测试放在后面也可以。经历团队项目之后，我发现这个想法很危险。

在团队项目 campus 中，前端模块之间、前后端接口之间都有依赖。比如登录鉴权会影响个人中心，课表导入会影响日程展示，AI 聊天和知识库又依赖外部服务和后端接口。如果只是等功能做完后再统一测试，一旦发现问题，很难判断是前端状态管理的问题、接口字段的问题，还是外部服务的问题。

实践让我认识到，测试不是项目末尾的“验收动作”，而是开发过程中的反馈机制。功能越多，越需要尽早把关键路径测起来。哪怕不是一开始就写完整自动化测试，也至少要在实现阶段明确：这个功能的正常输入是什么，异常输入是什么，接口失败时如何处理，用户看到的反馈是什么。

现在我的看法是：测试后置不是完全不行，但风险很高。越是多人协作的项目，越不能只靠“我本地跑过了”来保证质量。

问题五：敏捷开发是不是只是频繁开会和写博客？

学期初我对敏捷开发的理解偏形式化，以为它主要就是站会、迭代、燃尽图、博客记录这些东西。团队项目之后，我发现这些只是外壳，真正重要的是快速反馈和持续调整。

我们的团队项目是 6 人协作。项目推进过程中，需求、接口、人员分工和模块优先级都不是一开始就完全确定的。比如前端需要根据后端接口调整页面逻辑，根据项目进度决定先保证登录、课表、AI 聊天等主线功能，再逐步补充细节。这个过程如果完全按最初计划执行，很容易和实际情况脱节。

我现在对敏捷的理解是：它不是“每天开会”本身，而是团队能不能根据真实进展调整下一步行为。如果开会只是汇报流水账，那它没有意义；如果一次复盘能让团队改变任务拆分、接口约定、测试策略，那它就是有效的工程活动。

---

二、原来的问题还有哪些没有完全弄明白？

第一，AI 参与开发后的责任边界，我还没有完全想清楚。现在我知道不能盲信 AI，但如果团队中大量代码都经过 AI 辅助生成，那么 Code Review 应该审到什么程度，提交者需要对生成代码理解到什么深度，这仍然是一个值得继续思考的问题。

第二，PSP 到底应该记录到多细，我还没有标准答案。太粗会失去复盘价值，太细又会打断开发节奏。我目前的想法是记录到“能帮助下次估算”的程度，但这个尺度还需要更多项目经验才能把握。

第三，测试应该提前到什么程度，我也还没有完全实践过。我们更多是在实现过程中逐步补测试和调试，还没有真正做到严格的测试驱动开发。因此，我只能说自己体会到了测试缺位的代价，但还没有完整体验过 TDD 的收益。

---

三、新产生的问题

这一学期实践之后，我又产生了一些新的问题。

第一个问题是：AI 辅助开发越来越普遍之后，团队如何保证每个人都真正理解自己负责的模块？如果一个成员主要通过 AI 生成代码，再通过调试让它跑通，那么他是否真正具备维护这段代码的能力？

第二个问题是：在课程项目中，如何平衡“做出更多功能”和“把已有功能做稳”？团队项目很容易出现一种倾向：觉得多做功能更能体现工作量，但从用户角度看，一个稳定的核心功能往往比多个半成品功能更重要。

第三个问题是：学生团队项目中，文档应该写到什么程度最合适？文档太少，转会、交接、接口对齐都会出问题；文档太多，又可能变成维护负担。如何写出“够用但不过度”的文档，是我现在更关心的问题。

---

四、六个阶段中学到的知识点

1. 需求阶段：需求不是功能清单，而是用户场景

以前我容易把需求理解成“要做哪些功能”。但团队项目让我认识到，需求首先应该回答用户在什么场景下遇到什么问题。比如课表导入、AI 聊天、POI 详情这些功能，只有放到校园使用场景中，才能判断它们的优先级。如果只列功能清单，很容易每个都想做，最后主线反而不清楚。

2. 设计阶段：接口约定比临时对齐更重要

多人协作时，设计阶段最重要的知识点之一是接口契约。前端页面、mock API、类型定义、后端接口必须尽早对齐。否则实现时每个人都按自己的理解写，后面就会出现字段不一致、状态含义不一致、异常情况没人处理的问题。设计不是为了画好看的图，而是为了减少后续沟通成本。

3. 实现阶段：代码要为维护服务，而不只是为跑通服务

在个人写代码时，我以前更关注“能不能跑通”。但团队项目中，一个模块不只是自己看，还要让队友能接着维护。因此实现阶段要注意命名、目录结构、类型定义、配置分离和注释。尤其是登录鉴权、课表、AI 聊天这类会被多个模块依赖的功能，不能只追求当前页面能用，还要考虑以后如何扩展和排查问题。

4. 测试阶段：测试的核心是暴露边界条件

测试不是简单地点几下页面，也不是只测正常路径。真正有价值的测试应该覆盖异常情况和边界条件。比如登录失败、接口无返回、课表数据格式异常、AI 服务响应失败，这些情况在真实使用中都可能出现。如果测试只验证“理想情况下能跑”，就很难提前发现问题。

5. 发布阶段：发布不是最后一步，而是一套检查机制

发布阶段让我认识到，软件能在本地运行不等于可以交付。发布前需要检查环境配置、接口地址、构建结果、页面入口、兼容性和基本功能路径。个人项目中遇到过 Gitee Pages 部署成功但页面没有及时更新的问题，这让我意识到发布过程本身也需要验证，不能只相信平台提示。

6. 维护阶段：维护依赖可追踪的问题闭环

维护不是出了 bug 再临时修，而是要能追踪问题从发现到解决的全过程。比较理想的方式是：发现问题后记录 Issue，定位原因，提交修改，再验证关闭。这样做的意义不仅是修掉一个 bug，更是让团队知道这个问题为什么出现、以后如何避免。

---

五、个人项目、结对编程、团队项目的心得

个人项目阶段，我最大的感受是：软件工程不是只写代码。比如 Gitee Pages 的问题，表面看是页面没有更新，实际需要描述环境、复现步骤、期望结果、实际结果和证据截图。这让我第一次比较清楚地意识到，一个问题能不能被别人理解，取决于我能不能把它表达成可复现、可验证的工程问题。

结对编程阶段，我最大的收获是：沟通本身也是开发的一部分。《花见小路》项目中，我们不仅要写出能通过测试的代码，还要共同理解规则、讨论策略、分配编码和审阅角色。很多时候，对方提出的一个问题，会迫使我重新检查自己的设计是否真的合理。以前我觉得“解释代码”是写完之后的附加工作，现在我觉得能解释清楚，本身就是代码质量的一部分。

团队项目阶段，我最大的变化是开始理解“协作成本”。6 个人一起开发时，真正困难的地方不只是某个页面怎么写、某个接口怎么调，而是大家如何保持一致的目标、统一的接口、清楚的分工和稳定的节奏。我负责的前端模块比较多，越到后面越能感觉到：如果前期没有类型定义、mock 接口、页面入口和模块边界，后期就会不断出现返工。

把这一学期串起来看，我对软件工程的理解从“学习一些开发方法”变成了“用方法处理不确定性”。个人项目让我学习如何描述问题，结对编程让我学习如何共同理解问题，团队项目让我学习如何在多人协作中持续解决问题。

如果只从技术角度看，这门课可能就是写了几个项目；但从软件工程角度看，更重要的是我开始明白：代码只是软件的一部分，需求、设计、测试、发布、维护，以及人与人之间的协作，都会直接影响软件最后能不能真正完成。以前读书时看到这些概念，会觉得有些抽象；现在再看，很多概念背后其实都是项目中真实会遇到的麻烦。软件工程教的不是如何避免所有麻烦，而是如何用更系统的方法，让麻烦变得可发现、可讨论、可修复。