软工052201142_孙其煜学期回顾

学期回顾

回顾你对于软件工程课程的想象

学期初对软件工程这门课的期待，是跳出单打独斗的编程练习，真正经历一次完整的团队协作开发——从理解用户需求，到设计系统、编写代码，再到测试和部署，最终交付一个能被实际使用的软件。现在回头看，“以太校园”这个校园互助任务平台基本实现了这一目标。我们小组一起完成了整个系统的构建：用户通过微信小程序发布或接取任务，管理员则通过 Web 后台进行审核与管理。我在项目中主要参与了前端部分的开发，包括小程序端和 Web 管理后台的功能实现，使用 TypeScript 编写业务逻辑，并与后端同学紧密配合，确保接口对接顺畅、数据展示准确、交互体验合理。

在这个过程中，我不仅熟悉了小程序和 Web 前端的开发流程，更重要的是学会了如何在一个多人协作的环境中高效工作。比如，我们会一起讨论 API 字段命名是否清晰、某个操作是否需要加载状态、错误提示该如何友好呈现；在联调时，也会主动和后端对齐状态码含义，甚至一起排查是前端传参问题还是后端逻辑偏差。这种前后端之间频繁而具体的沟通，让我意识到软件开发不是“各自写完再拼起来”，而是从一开始就该协同演进的过程。同时，在使用 Git 进行分支管理、提交 PR、互相 Review 代码的过程中，我们也逐渐建立起一套属于团队的开发默契和质量意识。

当然，也有一些地方做得不够理想。比如前期对接口规范约定不够细致，导致后期有些字段需要反复调整；为了赶进度，部分页面的代码结构略显冗余，缺乏足够的抽象；测试也主要依赖手动验证，没有建立起对核心路径的自动化保障机制。这些不足，一方面是因为这是我们第一次完整走完一个团队项目，对节奏把控和风险预判还在摸索；另一方面也反映出在功能交付压力下，有时会不自觉地牺牲一些工程细节。但正是这些真实的挑战和调整过程，让我更清楚地认识到：软件工程的本质，不只是写出能跑的代码，而是在有限资源和时间下，通过有效协作，持续交付可靠、可用、可维护的系统。

回顾你在这门课程中的投入与产出

编写代码行数：管理端1k多行

小程序端1k多行

担任角色：前端

作业	花费时间
第一次团队作业	1天
第二次团队作业	1周
第一次团队项目作业	1天
第二次团队项目作业	3天
第三次团队项目作业	1周
第四次团队项目作业	1周

• 在软件工程课程上花费的时间

累计时间	实际周均时间	预计周均时间
600+h	52h	50h

令你印象最深刻的是哪一次作业或哪一场答辩？为什么这次作业或这场答辩令你印象深刻？

那时课程刚开始，大家对“要做一个什么样的项目”还很模糊，很多小组倾向于做课程表、二手书交易这类常见校园应用。而我们在前期做了简单的问卷调研和身边观察，发现一个更具体却常被忽略的问题：很多同学因为上课、实验或临时外出，无法及时取快递、打印资料，甚至错过食堂饭点，但又不好意思频繁麻烦朋友。于是我们提出了“以太校园”——一个基于信任和互助的任务发布与接单平台，核心不是交易，而是“顺手帮个忙”。

在那次答辩中，我们没有华丽的界面或成熟的技术方案，而是重点讲清楚了一个观察：校园里大量琐碎的小事——比如取快递、代打印、临时占座——常常因为“找不到人帮忙”或“不好意思开口”而被拖延甚至放弃。现有的社交方式（如朋友圈、群聊）虽然能发布求助，但信息容易被淹没，缺乏结构化和反馈机制。于是我们提出，“以太校园”的核心不是做一个交易平台，而是搭建一个轻量、可信、低门槛的互助通道，让“顺手帮个忙”变得简单、可追踪、有回应。

这个思路得到了老师的肯定。后来整个学期的开发方向，其实都源于这次选题时确立的初心。即使在后期遇到技术难题或时间压力，我们也会回头问自己：“这个功能是否真的服务于‘顺手帮忙’这个核心？”这种由选题阶段就锚定的产品意识，远比某段代码或某个框架更深刻地影响了我们的实践。也正因如此，第一次选题答辩在我心中格外特别——它不是一次形式化的汇报，而是我们整个项目灵魂的起点。

总结收获

2.1 展开说说你的软工实践故事

我们的软工实践，是从一个 GitHub 仓库和一张 AI 生成的 Logo 开始的。第一次作业看似简单——建团队主页、写成员介绍、设计 Logo——但正是这个“仪式感”让我们从松散的小组变成了有归属的团队。我们用通义千问生成了“以太校园”的 Logo：虽然只是图像，但它成了我们后续所有文档和演示的视觉锚点。而每位成员在 README 中写下的兴趣、技能和三年规划，也意外地成为后来分工的重要参考——比如谁熟悉 Java、谁有小程序经验，一目了然。

第二次作业要求构建一个“能说会做”的智能体。当时我们一度困惑：校园互助平台需要 AI 吗？直到想到可以让智能体自动解析用户发布的自然语言任务，比如“帮我取下东门快递，单号 SF123456”，并自动提取地址、快递公司、单号等结构化信息填入表单。于是我们用 Python 搭了一个轻量 MCP 兼容代理，调用本地 NLP 模型做意图识别，再通过 API 将结果推给 Java 后端。虽然最终因性能问题未集成到主系统，但这次尝试让我们意识到：AI 不是炫技，而是解决具体环节效率问题的工具。更重要的是，它为大项目中“智能任务解析”这一加分项埋下了伏笔。

第三次作业是选题答辩的关键节点。我们没有选择热门的二手交易或课程表，而是基于真实观察提出“以太校园”——一个非金钱驱动的互助平台。 这次经历让我明白：好的选题不在于技术多前沿，而在于是否扎根真实场景。

进入第四次作业的设计阶段，挑战真正开始。我们要把模糊的想法转化为可开发的蓝图。用墨刀画原型时，反复纠结“发布任务”流程该几步完成；画 UML 用例图时，争论“管理员是否应有权强制关闭任务”；设计数据库 ER 图时，为“任务状态机”是用枚举还是独立状态表讨论半天。最耗神的是前后端接口契约——我们第一次用 Swagger 写完整 API 文档，定义每个字段的类型、是否必填、错误码含义。那周几乎每天晚上都在对齐：小程序要的时间格式是字符串还是时间戳？Web 后台的分页参数叫 page 还是 pageNum？这些看似琐碎的约定，恰恰是避免后期联调灾难的防火墙。

第五次 Alpha 冲刺是开发的高潮也是低谷。我们原计划两周完成核心链路，但第一天就卡在微信登录授权与后端 JWT 集成上；中期又因服务器配置错误导致数据库连接池耗尽。最崩溃的是，某天合并代码后整个任务列表白屏，回溯发现是 TypeScript 类型定义和 Java 返回字段不一致。那段时间，我们每天站着开 10 分钟站会，只说三件事：昨天做了什么、今天做什么、有什么卡点。有人修 Bug，有人补测试，有人优化加载动画。正是这种高频同步，让我们在混乱中保持方向。冲刺结束时，虽然“信用评分”“消息推送”等功能被砍，但主流程——发布、接单、完成、评价——终于跑通了。

最后一次 Beta 冲刺，是打磨与“销售”。我们不再新增功能，而是修复体验细节：按钮点击反馈、错误提示文案、页面加载骨架屏。为了发布会，我们录了一段真实用户操作视频——一位同学用小程序发布“帮我打印第3教学楼302的资料”，另一位顺路接单完成。现场演示时，老师随机抽两位同学体验，当他们真的成功发布并接了一个任务时，我们所有人都松了一口气。那一刻我意识到：软件工程的终点，不是代码提交，而是用户真正用起来。

回看这六次作业，它们像一条清晰的成长轨迹：从建立团队身份，到探索技术边界，再到聚焦真实需求，继而规范设计，攻坚开发，最后交付价值。每一步都有狼狈，也有闪光。而“以太校园”之所以特别，不是因为它多复杂，而是它让我们看到：技术的温度，在于它如何轻轻托住那些微小却真实的日常需求。

介绍学习到的新技术或生产力工具以及它们给你带来了哪方面的帮助？

• TypeScript：在微信小程序和 Web 管理后台开发中全面采用 TypeScript，通过静态类型检查显著减少了因字段名错误、参数类型不匹配导致的运行时 bug，尤其在与 Java 后端对接复杂接口时，明确定义 interface 让前后端协作更可靠、调试更高效。

• Git 与 GitHub 协作流程：通过创建 feature 分支、提交 Pull Request、进行代码 Review 和讨论后再合并，有效避免了多人直接推送 main 分支造成的代码冲突和逻辑覆盖，使每次变更可追溯、可回滚，极大提升了团队协作的规范性和安全性。
  

• Swagger（OpenAPI 规范）：作为前后端接口契约的核心工具，我们用它统一维护 API 文档，明确每个接口的路径、请求方法、参数格式、响应结构及错误码。这大幅减少了“我以为你传了这个字段”的沟通成本，联调效率明显提高。

• figma：用于测试和保存后端 Java 接口的请求集合，支持设置环境变量（如 dev/test/prod）、编写简单断言验证响应，还能将测试集共享给前端成员，方便他们独立验证接口可用性，减少对后端同学的依赖。

• Vite：作为 Web 管理后台的构建工具，其极快的冷启动和热更新速度显著提升了前端开发体验，修改代码后几乎瞬时反映在浏览器中，让 UI 调试和交互优化变得流畅高效。

• 微信开发者工具 + 真机调试：深入使用其性能分析、网络监控、日志查看和真机同步功能，帮助我们发现并修复了小程序在低端机型上的卡顿、授权流程异常等问题，确保上线前体验达标。
  

• 墨刀（MockingBot）：在设计阶段用于绘制高保真、可交互的原型，包括小程序用户流程和 Web 后台管理界面。通过在线链接分享给全组和助教，快速收集反馈，避免了“理解偏差”导致的返工。

• Nginx + 阿里云 ECS：首次完整实践从本地开发到线上部署的全过程。通过 Nginx 配置反向代理、HTTPS 证书、静态资源托管，成功将 Web 后台和 Java 后端服务部署上线，理解了生产环境的基本运维逻辑。

• MCP（Model Context Protocol）兼容框架（Python 轻量 Agent）：在第二次作业中尝试构建智能体，用于解析用户自然语言任务（如“帮我取东门快递”），虽未集成至主系统，但让我们初步掌握了 AI Agent 的基本架构与工具调用机制，为项目加分项打下基础。

这些工具和技术不仅提升了开发效率和代码质量，更重要的是让我体会到：现代软件工程是“工具链驱动”的协作过程，善用工具本身就是一种核心工程能力。

技术之外，这门课程还给你带来了哪些方面的提升？

• 沟通表达能力的提升：学会用清晰、结构化的方式描述问题，比如在站会中说明“卡点是接口返回 401，怀疑 Token 过期”，而不是笼统说“登录不了”；在 PR 评论中给出具体修改建议，而非只说“这里不好”。
• 团队协作与责任意识增强：理解到每个人的工作都环环相扣，主动同步进度、及时响应队友请求成为习惯；对自己负责的模块保持“ownership”，即使没人催，也会主动测试、优化和补充注释。
• 用户视角的建立：不再只关注功能是否实现，而是思考“用户会不会困惑？”“操作步骤是否太多？”“出错时有没有明确指引？”。例如，我们在小程序任务发布页增加了示例文案和必填提示，显著降低了用户输入错误率。
• 时间管理与优先级判断能力：通过制定周计划、拆解任务、设置缓冲期，逐渐摆脱“最后一晚通宵”的被动节奏；在需求变更时，能和团队一起评估影响，优先保障核心路径，学会对非关键功能说“先不做”。
• 接受不完美与迭代思维：认识到在真实项目中，100 分的设计往往不如 80 分但按时交付的可用版本。我们砍掉了初期设想的“智能推荐”“实时聊天”等功能，聚焦主流程，反而让产品更稳定、更早可用。
• 文档与规范意识的养成：从最初忽略接口文档，到后来主动维护 Swagger、更新 README、编写部署说明，意识到“写文档不是负担，而是对团队和未来自己的尊重”。
• 抗压与问题解决心态的转变：面对联调失败、部署报错、提审被拒等挫折，从最初的焦虑慌乱，逐渐转向冷静排查日志、复现问题、分工验证，把“出问题”看作优化系统的机会而非灾难。

三、致谢

一个学期的软件工程实践走到尾声，回望“以太校园”从一行 README 到线上可运行的系统，每一位成员都付出了努力

其实我们没有谁是“负责人”，但每个人都把自己当作项目的主人。无论是深夜的 GitHub 提交、群里的快速响应，还是答辩前互相演练问答，这些点滴让我明白：好的团队不是没有困难，而是遇到困难时，没人说“这不关我事”。

这段并肩作战的日子，远比一个课程成绩更珍贵。希望“以太校园”不只是我们的作业，也能真的成为校园里一点微小却温暖的连接。