软工总结

一、学期回顾
1.1 回顾你对于软件工程课程的想象
刚选上软件工程这门课的时候，我对它的想象主要有两点：一是能系统地把之前零散学到的编程知识串起来，从“会写代码”变成“会做工程”；二是通过一个完整的团队项目，真正体验一次从需求到上线的全流程，而不是只写几个小实验。

从结果来看，这学期在几个方面基本达到了我的预期：

对“工程化”的理解更立体了
以前做后端更多是“实现需求 + 接好接口”，这次在团队项目里，从一开始就要考虑接口设计、模块划分、错误码、日志、配置、部署方式这些东西，例如在 go-mcp-demo 里，后端需要同时对接 HTTP Host、MCP Server 和大模型服务，整体结构必须一开始就想清楚，否则后面非常难改。​
GITHUB
对协作开发的流程更熟悉了
代码不再是自己一个人的 repo，而是多人同时在上面开发，要按照约定的分支模型提 PR、review、合并，提交信息也要写清楚，不然回溯问题非常痛苦。这部分体验和我一开始的期待是一致的。
当然，也有没做到位的地方：

测试与文档依然偏弱
虽然有写单元测试和少量接口测试，但更多还是“临时补一补”，没有形成很完整的测试策略；文档方面，README 和接口文档主要围绕“怎么跑起来”和“怎么调接口”，对于内部模块设计、关键设计取舍记录得不够，这点和我一开始期待的“更规范、更全面”还有差距。
时间与复杂度预估不足
一开始低估了后端系统复杂度，尤其是涉及会话管理、对话总结、流式交互这些能力时，很多细节是踩着坑才补回来的。结果就是中后期有几次赶工，时间分配有点紧绷。
整体来说，这门课确实把我从“写功能”往“做工程”往前推了一大步，但在测试、文档和时间管理上，仍然有比较明显的提升空间。

1.2 回顾你在这门课程中的投入与产出
在软工实践课程当中，我个人大概编写了 约 4,200 行代码（按 git diff 粗略估算，包含后端业务代码、配置脚本和部分测试），主要集中在 go-mcp-demo 仓库的 Host、会话管理与总结相关模块上。
在团队项目中，我参与了 「go-mcp-demo」 的设计与开发，主要承担 后端核心开发 / 服务编排 的角色，包括接口设计、会话/模板相关逻辑实现、部分中间件与配置管理，以及和队友一起调通完整链路。
软工实践的各次团队作业（估算为个人投入时间）：
作业 花费时间
第一次团队作业 4 h
第二次团队作业 5 h
第一次团队项目作业 10 h
第二次团队项目作业 15 h
第三次团队项目作业 18 h
第四次团队项目作业 20 h
在软件工程课程（含理论课 + 实践课 + 项目）的总体时间投入估算如下：
累计时间 实际周均时间 预计周均时间
110(h) 9(h) 6(h)
一开始以为每周 6 小时左右可以搞定，实际做起来发现团队项目中后期非常吃时间，尤其是联调与排查 bug 的阶段，经常一改就是一个晚上。

1.3 令你印象最深刻的是哪一次作业或哪一场答辩？
我印象最深的是最后一次团队项目答辩。

那次答辩之前，我们刚刚把后端的对话系统整个串起来：Host 通过 HTTP 接收请求、转发给 MCP Server，再和大模型服务交互，最后把带记忆的对话结果返回给前端。中间涉及到配置、网络、超时、错误处理等一堆细节，前几天还频繁出现“本地没问题，服务器报 500”的情况。

为保证答辩现场尽量稳定，我和队友提前做了几件事：

把核心接口（创建会话、发送消息、总结会话）用 Apifox/Swagger 跑了一遍，确保基本场景可用；
对一些不太稳定的部分加了降级和错误提示，比如上游大模型超时时，接口能给出明确的错误信息而不是直接 panic；
准备了几组典型 demo 场景，比如长对话后的总结、不同用户之间会话隔离等。
答辩当天，当老师在现场输入一段对话并让我们展示“对话总结”能力时，我盯着终端日志，看到所有请求都顺利走完那几条链路，心里一下子踏实了。那一刻会有一种“之前所有熬夜、踩坑，都变成了一个很直观的结果”的感觉，所以印象特别深刻。

二、总结收获
2.1 展开说说你的软工实践故事
如果用几个关键词来概括这学期的软工实践，我会选：从 0 到 1、后端支柱、一次次的重构和取舍。

第一次团队作业：团队搭建与协作方式
这一阶段主要是搭建 GitHub 团队仓库、分配基础角色。虽然看上去是“简单作业”，但从那时开始我们就约定了分支命名、提交规范，以及用 issue/PR 来讨论需求，这为后面项目的协作打了一个底。

团队项目前期：先把东西“跑起来”
在项目起步阶段，我们优先做的是 端到端打通：把 Hertz 的 HTTP Host 跑起来，再把请求转发到 MCP 模块和大模型服务上，哪怕一开始逻辑比较“糙”，但至少能证明路径是通的。作为后端主力，我主要负责：

设计会话与消息相关的接口（例如获取会话、创建会话、发送消息与总结接口）；
规划后端模块结构，把 Host、应用层逻辑、存储/配置等拆开；
和队友一起确定错误码、返回体结构，让前后端沟通成本更低。
中期：从“能用”到“靠谱”
终端能跑起来之后，真正的挑战才开始：异常处理、权限校验、会话隔离、配置管理……
比如在会话总结这一块，不能只把对话扔给大模型就算完成，还要考虑：

用户只能操作自己名下的会话，避免越权访问；
会话不存在或已被删除时要给出明确提示；
总结失败时不能影响原始对话内容的安全性。
这些逻辑都促使我们反复重构代码，把一些临时写在 Handler 里的判断抽到应用层或统一的错误处理中去。
后期：性能、可维护性和“以后怎么办”
后期在基本功能稳定的基础上，我们开始思考一些更工程化的问题，比如：

配置文件如何拆分 dev/prod；
如何用 Docker 和 Makefile 让“拉下代码就能跑”尽量简单；
以后如果要替换模型服务，能不能只改一处配置或一层适配代码。
虽然课程项目到这里就结束了，但在这个过程中，我第一次认真去想“如果这个项目以后真的要维护一年，会有哪些坑必须一开始就填”。
整体回顾下来，我在项目里最核心的收获，是从“我写了一堆 Go 代码”升级成“我参与搭了一套后端服务，并能解释清楚它为什么要这么设计”。

2.2 介绍学习到的新技术或生产力工具，以及它们给你带来了哪方面的帮助？
这一学期接触和加强使用的技术 / 工具主要有：

Go + Hertz 后端开发栈

熟悉了 Hertz 这种高性能 HTTP 框架的路由、中间件、上下文使用方式；
在实际项目中尝试了分层结构（handler / application / repository）的写法，让代码更易于测试和重构。
MCP 相关协议与多服务协作

在项目中体验到“一个 Host 调用多个下游服务”的模式，让我对服务间通信、接口设计和超时重试有了更直观的理解。
Swagger / OpenAPI + Apifox/Postman

使用 OpenAPI 描述接口，再导入到 Apifox 等工具中进行调试，大大减少了手写 curl 的时间；
也帮助前后端在接口对齐上少吵了很多架（笑）。
Docker + Makefile

通过 docker-compose + Makefile，把项目的启动流程封装成一条命令，让“换一台机器跑起来”没有那么可怕；
也初步感受到“环境即代码”的思路。
Git 协作与 Code Review

更系统地使用分支管理和 PR 流程，学会了在 review 中关注代码可维护性、错误处理和边界情况；
也体验到“写给别人看的代码”和“只给自己看的代码”差别有多大。
2.3 技术之外，这门课程还给你带来了哪些方面的提升？
除了技术栈本身，我在几个“软技能”上的提升也非常明显：

需求沟通与抽象能力

学会把“老师一句话的需求”拆成若干具体的接口和数据结构；
遇到描述模糊的地方，会主动拉团队开小会澄清，而不是默默实现一个自己脑补的版本。
时间管理与优先级意识

在多门课程和项目并行的情况下，学会了给任务排优先级：先确保主流程可用，再慢慢补细节和优化；
比之前更敢于说“不”，比如在时间不够时果断砍掉一些非核心的小功能。
团队合作与角色意识

作为后端主力，有时候需要在“自己写代码”和“帮队友解 bug / 解释后端逻辑”之间做取舍；
这门课让我更清楚地意识到：一个团队里，每个人的角色都不是孤立的，能把别人也“带顺”是一种很重要的能力。
面对不确定性的心态

项目中有不少“第一次做”的东西，比如某些第三方服务的集成、一开始完全没接触过的协议；
一开始会很慌，但慢慢习惯了“查文档 + 搜 issue + 小步试错”的节奏，对未知的东西不再那么恐惧。
2.4 其他想记录的 / 想说的话
如果说这门课对我最大的改变，大概是让我更认真地思考了自己未来想往哪里走。

在做 go-mcp-demo 的过程中，我发现自己对 后端架构、服务编排和工程化细节 这块是有兴趣的：看到一堆服务通过配置和接口被串起来，日志里一条条请求干干净净地流过，这种“有秩序地运转”给我的成就感其实不比写出一个花哨的前端页面少。

当然，也有遗憾：有些地方如果能更早做规划，比如日志规范、统一错误处理、中间件抽象，后面重构时就不会那么痛苦；有些想做的小优化（例如更完善的监控或指标统计）因为时间关系最终没能落地，只能留给未来的自己或者后来者。

想给未来 Z 班的学弟学妹留一句话的话，大概是：

别把这门课只当成“期末有大作业的专业课”，而是当成一次“小型版真实项目”的模拟机会。
敢在这里多踩坑、多试错，你以后在真正的项目里会感谢现在的自己。

三、致谢
一个学期下来，如果要说感谢，我最想感谢的有三类人：

授课老师和助教
谢谢老师在课堂上把抽象的工程理论讲清楚，也愿意在我们项目设计“走偏”的时候点醒我们；谢谢助教在对接作业和项目时的耐心解答——很多看似“只是作业要求里的一个小条目”，其实背后都有非常工程化的考虑。

团队里的每一位队友
在项目推进的艰难时刻，总有人在熬夜陪你调 bug；在需求讨论吵得不可开交的时候，最后大家又能回到“怎么把这件事做成”上来。这种互相拉一把的体验，是我对这门课最珍惜的部分之一。

在课内课外给过我建议的同学们
有同学分享自己的项目经验，有人帮忙看了一眼奇怪的报错，有人给了我对架构设计的不同视角——这些零零碎碎的帮助，加起来其实对我影响很大。

最后，想对所有一起走完这个学期的人说一句：谢谢你们陪我一起把一个“看上去有点吓人”的课程，变成了一段挺值得回味的经历。希望以后再看到这份总结的时候，会想起的是那几次通宵调试后的成功运行，而不是某次翻车的崩溃瞬间