学期回顾

一、学期回顾

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

在学期初，我对“软件工程”这门课的想象，其实是一片空白的。由于此前从未有过完整的项目开发经历，我对它的理解还停留在非常浅显的“写大作业”层面——天真地以为它只是把平时课后作业的代码量放大十倍，大家分头写几个函数，最后拼在一起就能跑起来。我甚至以为，只要我把 Java 语法背熟、把 Spring Boot 教程看懂就可以了。
然而，随着“以太校园”项目的真正启动，我才深刻意识到：原来写程序和做工程是完全不同的两个概念。
如果说学期初的我，把软件工程看作是一个人的编码，那么现在的我更愿意把它理解为一次一群人的排雷。它教会我的不仅是 Spring Boot 或 AI 技术，更是一次参与工程开发的宝贵经验。比任何技术细节都更宝贵的启蒙。

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

编写代码行数 2k+

实现商品搜索、展示、任务发布功能

担任角色：后端

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

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

累计时间	实际周均时间	预计周均时间
300+h	30h	20h

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

印象最深刻的是第二次汇报前夕遇到令人头疼的 bug。

第二次汇报前夕，是黎明前的至暗时刻。那时我们正为了赶进度，多人同时在 Main 分支上直接提交代码。由于初期分支管理松散，我们遭遇了一次“代码刺客”——一次粗暴的 Merge 冲突解决，直接覆盖了队友熬夜刚写好的鉴权逻辑（Security Filter）。
上一秒大家还在为新功能跑通而欢呼，下一秒整个项目就陷入了崩溃：登录失效、接口 401、控制台报错刷屏。那个深夜，看着 Git 树上错综复杂的提交记录，我们花了很长的时间才解决问题。我们也深刻意识到规范的重要。

二、总结收获

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

我们的软工实践，像一场从“混沌”走向“有序”的旅程。没有一开始就完美的蓝图，只有在一次次试错、沟通与重构中，逐渐打磨出一个真正可用的产品。

第一阶段：需求迷雾，从“想当然”到“真痛点”
项目初期，我们对产品的构想充满了天真。最初大家只是想做一个炫酷的“校园综合平台”，恨不得把二手交易、课程表、论坛全塞进去。直到我们真正走出宿舍，去采访了身边的同学，并在激烈的讨论后，我们将核心聚焦于“基于信任的校园互助任务”，这才是“以太校园”真正的灵魂起点。

第二阶段：架构设计 vs 快速验证的拉锯
在技术选型时，团队一度陷入了“过度设计”的问题。有人主张直接上微服务（Spring Cloud），觉得这样才显得技术牛；又有人认为在有限的工期内，单体应用的稳健性优于微服务的复杂度。 争论持续了两天，最终我们达成了共识：“先用最简架构跑通核心业务”。于是我们确立了 Spring Boot 3 + Spring AI 的技术栈。

第三阶段：联调阵痛，规则在崩溃中诞生
第二次汇报前夕，是黎明前的至暗时刻。由于初期分支管理松散，我们遭遇了一次粗暴的 Merge 直接覆盖了队友刚写好的鉴权逻辑，导致项目崩溃，从那之后我们就制定了铁律：Feature 分支开发、PR 必须 Review、接口文档十分重要。

最后阶段：从“交付作业”到“交付价值”
当我们早已满足了作业的评分标准时，团队却没人想停下来。于是，团队决定引入阿里云 OSS 做动静分离，优化 SQL 查询降低 AI 响应延迟；增加加载动画，优化错误提示。

软件工程教会我们的，从来不是如何写出完美的程序，而是如何在不完美中，与队友背靠背，一步步靠近更好。

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

• 协同开发与版本管理流（Git Flow）
  从最初随意的提交，到后来严格的分支管理与 Code Review。它带来的帮助不仅是代码安全，更是一种“互相负责”的机制。每一次合并请求的审查，都是团队成员间无声的技术交流与质量把控。
• Spring AI 与大模型集成框架
  这不仅仅是一个新框架，它改变了我对后端的认知。它帮助我将非结构化的自然语言（如用户发帖、评论）转化为结构化的业务数据，让我学会了如何将“不确定”的 AI 能力驯化为“确定”的业务逻辑，极大地拓展了系统的智能边界。
• 云原生存储与服务部署
  通过实践动静分离和线上部署，跳出了本地开发的舒适区。我们建立了“服务”的概念——代码写完只是开始，如何让它在真实的互联网环境下高效、稳定地触达用户，才是工程的终点。

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

• 有效沟通
  最开始开会时要么整体沉默，就产品经理自说自话。要么就是各执己见，意见总是得不到统一。好在通过不断的磨合，我们开始有序的发现不错过每一个观点，让每一个观点可以萌芽。
• 时间管理与任务拆解能力
  将宏大的系统目标拆解为一个个清晰、可落地的原子化任务。同时应该给每一个子任务规定一个期限不然面临后续工作无法及时开展的困境。比如项目问题未及时解决，导致汇报 ppt 也无法及时完成。
• 抗压能力与冷静破局
  计划赶不上变化是不可避免的，在截止日期将至时，跳出来的一些没遇到过的 bug 导致集体赶工，好在最终化险为夷，让系统重回正轨。
• 服务意识与用户视角
  产品的最终目标是服务于客户，我通过这次项目经历学会了跳出后台逻辑的自嗨，学会如何让响应机制更符合用户直觉。这种从“完成功能”到“交付体验”的思维跨越。
• 文档习惯与知识沉淀意识
  文档与规范是团队的隐形资产。清晰的代码注释、及时的文档更新，不仅仅是为了方便当下，更是为了未来的可维护性。

2.4 如果还有什么想记录的或者想说的，就写在这儿吧！

如果用一句话总结这门课对我职业生涯的影响。在此之前，我眼中的后端只是 CRUD 和复杂的 SQL；而现在，我明白了后端的真谛在于承载数据的安全、承载前端的信任、承载业务的流转。

三、致谢

首先感谢老师的悉心指导。

感谢我的组员们，谢谢大家的相互包容相互理解，谢谢你们在联调时的耐心配合。这门课让我知道，一个完好的项目离不开每一个成员的共同努力。
愿“以太校园”不止停留在这次课程之中，更能承载着我们这段协作的记忆，成为我们工程生涯中浓墨重彩的一笔。