学期回顾

学期回顾

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

刚开学时，我对软件工程课程的想象主要集中在三点：

• 能够系统地学习一套从需求分析到上线运维的完整开发流程；
• 能够真正做出一个“能被真实用户使用”的系统，而不只是课堂上的玩具示例；
• 能够在实践中提升自己在团队协作、代码规范、工程化思维等方面的能力。

结合这学期完成的 AetherNet 校园互助与动态平台（微信小程序 + Spring Boot 后端），我觉得在以下方面基本达到了最初的期待。

首先是端到端的完整开发体验。
从最初的需求理解，到后端 REST API 设计，再到微信小程序前端页面实现，我完整走了一遍“需求 → 设计 → 编码 → 联调 → 部署 / 调试”的闭环。例如：

• 设计并实现了互助任务模块：任务发布、任务列表、任务接单、放弃任务、任务状态流转（open → ongoing → completed / cancelled）等；
• 完成了动态（帖子）模块：帖子发布、编辑、删除、点赞、收藏、评论与回复、评论点赞等；
• 实现了个人中心相关功能：个人信息设置、头像 OSS 上传、任务管理（“我发布的任务”“我承接的任务”）等。

其次是工程化与规范意识的提升。
在项目中，我逐渐不再“只求能跑起来”，而是开始关注系统层面的规范性，例如：

• REST 接口的语义一致性（如 /api/public、/api/student、/api/admin 分层）；
• 后端统一返回 Result<T>，分页统一使用 PageResult<T>，前后端协议更加清晰；
• 微信小程序端尽量复用 utils/api.js 中的请求封装，减少重复代码。

同时，我在问题定位与重构能力上也有明显提升。
例如在学期后期，我们集中重构和修复了一些关键问题：

• “我承接的任务”中放弃任务时，正确调用 POST /api/student/tasks/{taskId}/giveup，并在后端将 assignee_id 置为 null、status 改为 open；
• 修复互助任务列表在接单 / 放弃后前后端状态不同步的问题；
• 将头像上传统一为调用 POST /api/public/oss/upload，并保存 OSS 返回的 URL，真正打通前后端流程。

当然，实践过程中也暴露出一些不足：

• 自动化测试与质量保障不足
  项目主要依赖手工测试和小程序真机调试，缺乏系统性的单元测试与集成测试，导致高风险功能修改时需要反复手测，bug 容易回归。

• 前期需求与设计不够细致
  一些交互和接口是在“做到一半再调整”的过程中逐步完善的，例如任务列表分类逻辑、动态模块中列表页与详情页状态同步问题，反映出前期需求梳理和接口设计仍不够充分。

• 时间管理与迭代节奏有待提升
  个别迭代前期节奏偏松，后期集中赶工，对代码质量和个人状态都有一定影响。如果能更早拆解任务并推进 demo，会更理想。

---

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

编写代码行数与角色分工

在软工实践课程中，我个人大约编写了 约 2800 行代码（不含自动生成代码），主要分布在：

• 微信小程序端

  • 互助任务模块：pages/help、pages/my_tasks、pages/my_help
  • 动态模块：pages/social、pages/post_detail、pages/my_posts
  • 个人中心与设置：pages/profile、pages/setting、pages/profile_edit

• 后端协作部分

  • 协助调试和修改 TaskController、PostController、CommentController、StudentUserController 等接口；
  • 参与 TaskServiceImpl 中任务状态流转、接单 / 放弃逻辑的修正。

我在项目中主要承担的角色是：

• 微信小程序端核心开发；
• 后端接口对接与联调；
• 部分接口文档与说明整理。

作业与时间投入情况

作业	花费时间
第一次团队作业	1 天
第二次团队作业	6 天左右
第一次团队项目作业	1 天
第二次团队项目作业	3 天
第三次团队项目作业	6–7 天
第四次团队项目作业	7 天左右

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

累计时间	实际周均时间	预计周均时间
560+ h	48 h	45 h

令你印象最深刻的一次作业或答辩

令我印象最深刻的是互助任务模块完善与答辩那一次迭代。

在这一轮中，我们集中解决了几个看似细小但对系统一致性至关重要的问题：

• 放弃任务后数据库状态必须完全回退，避免逻辑残留；
• 接单 / 放弃后任务列表必须通过接口刷新，而不是只改前端本地状态；
• 头像上传从本地路径改为完整的 OSS 上传与 URL 回显链路。

在答辩展示中，当我们完整演示“发布任务 → 接单 → 放弃 → 任务重新回到互助大厅”的全过程时，所有前后端逻辑与界面反馈都自然衔接起来。那一刻我清楚地感受到：

这已经不再是零散的功能点，而是一个真正“活着”的系统。

这次经历让我深刻体会到，软件工程的价值不在于单个功能是否炫酷，而在于整体流程是否闭环、细节是否可靠。

---

总结收获

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

这次软件工程实践，并不是从敲代码开始的，而是从一次对“我们要解决什么问题”的反复讨论中逐渐成形。项目初期，我们并没有明确的技术野心，而是希望先找到一个在校园中真实存在、且值得被认真对待的问题。在不断交流和观察中，我们意识到，许多校园里的小需求并非无法解决，而是缺乏一个合适、低门槛的协作渠道。正是在这样的背景下，“以太校园”逐渐从一个模糊的想法，演变为一个以互助为核心的系统构想。

在最早的团队协作阶段，我们开始真正体会到“软件工程”与个人编程练习的区别。相比代码本身，如何分工、如何对齐理解、如何保证每个人做的部分最终能拼接成一个整体，成为更现实也更棘手的问题。通过编写团队主页、统一项目仓库结构、明确模块负责人，我们逐渐建立起一种基本的协作秩序，也第一次感受到“工程感”带来的约束与效率。

随着项目推进，实践的重心开始转向系统设计与实现。在这一过程中，我明显感受到，从需求到功能之间并不存在一条笔直的路径。很多在讨论中看似简单的功能，在真正落地时都会暴露出新的问题：接口边界是否清晰？状态如何流转才合理？异常情况应该如何处理？这些问题迫使我们不断在“设计—实现—推翻—再设计”的循环中前进。也正是在反复调整中，我逐渐理解了设计并不是一次性完成的，而是伴随实现不断被验证和修正的过程。

进入开发密集期后，项目的复杂度开始显现。功能逐渐增多，模块之间的依赖关系也更加紧密，一个看似局部的修改，往往会影响到多个页面或接口。这一阶段让我印象最深的，不是某个具体功能的完成，而是团队在问题出现时的应对方式：通过同步进度、拆解问题、逐个验证假设，最终把系统重新拉回可控状态。我开始意识到，稳定推进项目的关键，并不在于每个人写得有多快，而在于团队是否始终对系统整体保持共识。

在后期的迭代中，我们逐渐把注意力从“有没有功能”转向“用起来是否顺畅”。一些早期被忽略的细节开始变得重要：提示文案是否清楚、页面反馈是否及时、操作路径是否冗余。虽然这些调整并不会在功能列表中显得耀眼，但它们直接决定了系统是否真的“可用”。这一阶段让我第一次从开发者视角跳出来，尝试站在用户的位置审视自己写下的代码。

回顾整个实践过程，我最大的感受是：软件工程并不是一系列技术任务的简单叠加，而是一种在约束中不断权衡与取舍的过程。时间、人员、能力都有限，不可能把所有设想一次性实现，但通过持续迭代，依然可以交付一个完整、稳定、具备实际价值的系统。正是在这样的实践中，我逐渐完成了从“写功能”到“做工程”的转变。

这段软工实践并不完美，但它足够真实。它让我清楚地认识到，软件工程的意义，不仅在于最终交付了什么，更在于我们如何作为一个团队，把一个抽象想法一步步变成可运行、可使用、可维护的系统。这一认知，将会在我之后的学习和实践中持续发挥作用。

---

介绍学习到的新技术或生产力工具以及它们带来的帮助

• 微信小程序开发框架：熟悉了页面生命周期、路由机制与组件化开发，能够更系统地组织前端代码。
• Spring Boot + MyBatis-Plus：掌握了常见 REST 接口实现方式及分页、用户绑定等后端逻辑。
• 阿里云 OSS：完整理解了文件上传从前端到云存储的工程链路。
• API 调试工具（Postman / Thunder Client）：显著提升了接口联调与问题定位效率。
• Git 协同开发流程：通过分支与合并减少冲突，提高协作安全性与可追溯性。

这些工具让我更加明确：现代软件工程是一种高度依赖工具链的协作实践。

---

技术之外，这门课程还带来的提升

• 需求表达与文档规范意识显著增强
  在多轮作业与项目推进过程中，我逐渐认识到清晰的需求描述和规范化文档并不是“附加工作”，而是保障团队协作效率与开发质量的基础。这种意识的建立，使我在后续工作中能够更加主动地进行需求澄清、接口说明与设计记录。

• 时间管理与任务拆解能力得到系统性提升
  面对阶段性目标明确、交付节点固定的实践任务，我学会将抽象的大目标拆分为可执行的小任务，并为其分配合理的时间预期。这一过程不仅减少了拖延和返工，也让我对个人工作节奏有了更清晰的掌控。

• 团队协作中的责任意识与角色认知不断强化
  在多人协作的开发环境中，我逐渐从“完成自己部分即可”的心态，转变为主动关注整体进度与质量。这种对结果负责、对团队负责的意识，使我更加理解软件工程中“ownership”的真正含义。

• 思维方式由功能实现转向工程化视角
  相比单纯追求功能是否可用，我开始更多地思考系统结构是否合理、接口是否稳定、方案是否具备可维护性与扩展性。这种从“能不能做”到“是否值得这样做”的转变，是本课程带给我最深刻的思维提升之一。

---

致谢

一个学期的软件工程实践走到尾声，我想感谢课程老师与助教的耐心指导，也感谢项目组每一位并肩作战的队友。

我们一起经历了需求反复、bug 集中、临近 ddl 的紧张，也一起完成了从想法到系统的全过程。正是这些真实而具体的合作，让我真正理解了：

好的软件工程，不只是写代码，而是一群人对同一个目标的长期负责。

这段经历，将会是我学习与成长过程中非常重要的一部分。