学期回顾

一、学期回顾

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

在学期初，我对“软件工程”这门课的想象，更多停留在“写代码 + 做项目”的层面——以为它只是将之前学过的编程语言、数据结构、数据库等知识整合起来，完成一个功能完整的系统。我甚至天真地认为，只要技术够硬、逻辑清晰，就能顺利交付一个“能跑就行”的产品。

然而，随着课程的推进，我才真正意识到：软件工程远不止是“写代码”，而是一门关于协作、规划、沟通与持续迭代的系统性工程。从需求分析、原型设计，到版本控制、测试部署，再到用户反馈与产品优化，每一个环节都深刻影响着最终成果的质量与生命力。

在这门课中，我确实达到了当初的部分期待：比如亲手参与了一个从0到1的产品开发全过程，掌握了团队协作开发的标准流程（如Git协作、CI/CD等），也提升了工程化思维。但我也看到了自己的不足——例如在初期对需求理解不够深入，导致后期返工；又比如在时间管理上缺乏经验，曾因低估任务复杂度而陷入赶工焦虑。

如果说学期初的我，把软件工程看作一场“技术秀”，那么现在的我更愿意把它理解为一次“团队共创的艺术”。它教会我的不仅是如何构建软件，更是如何与人合作、如何面对不确定性、如何在混乱中建立秩序——这些，或许比任何一行代码都更珍贵。

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

• 编写代码行数 8000+
• 参与了“以太校园”项目的设计与开发，我所承担的角色是后端开发&前后端联调
• 软工实践的各次作业分别花费的时间：

作业	花费时间
第一次团队作业	1h
第二次团队作业	1h
第一次团队项目作业	2h+
第二次团队项目作业	1h
第三次团队项目作业	12h+
第四次团队项目作业	12h+

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

累计时间	实际周均时间	预计周均时间
42h	3h	2h

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

如果要选出本学期最令人难忘的时刻，那一定是倒数第二次答辩。

那时，我们的项目正处于“功能勉强能跑，但处处是坑”的阶段。前端页面在不同浏览器上渲染不一致，后端接口偶尔返回500错误。更雪上加霜的是，距离答辩只剩48小时，部分功能的业务逻辑还存在问题。

那两天，有人通宵优化前端页面，有人重写前端状态管理逻辑，还有人手动测试每一个接口功能。

而真正让我们铭记这次答辩的，不只是技术上的突破，更是那一刻的团队凝聚力。当我们在答辩现场流畅演示修复后的系统，那种“我们一起扛过来了”的默契与成就感，至今想起仍心头一热。

二、总结收获

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

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

第一阶段：需求模糊，方向摇摆
项目初期，我们对用户痛点的理解停留在表面。比如最初设想做一个“信息整合平台”，但到底整合什么？类似的软件是否已经被开发过了，是否要换主题？大家各执一词。在经过讨论后，才聚焦到“校内信息杂乱，信息差严重，垃圾信息审核不当”这一核心问题。

第二阶段：架构设计 vs 快速验证的拉锯
在技术选型时，团队一度陷入“过度设计”的陷阱。有人主张上 springcloud，有人坚持单体应用更稳妥。争论持续了两天，进度停滞。后来我们采纳了助教的建议：“先用最简可行架构跑通核心流程，再横向扩展。”于是我们用 springboot + react 搭建了 MVP（最小可行产品），三天内就验证了杀手级功能的可行性。

第三阶段：Git 冲突、代码回滚与 CI/CD 的救赎
开发中期，由于分支管理混乱，曾出现过一次严重的合并冲突，导致前端页面直接白屏。那天晚上，我们花了三个小时手动比对 diff，几乎崩溃。痛定思痛后，我们立刻制定了 Git 工作流规范：feature 分支命名、PR 必须 review、主干保护。

最后阶段：从“交付作业”到“交付价值”
临近终期，我们不再只盯着评分标准，而是思考：“如果真有用户用这个产品，他们会满意吗？” 于是我们增加了错误提示友好度、优化了加载动画、甚至加了一个小小的“引导页”。

回望这段旅程，每一次讨论、每一个深夜的 debug、每一行被删掉又重写的代码，都成了“轻舟”穿越“万重山”的桨声。软件工程教会我们的，从来不是如何写出完美的程序，而是如何在不完美中，一步步靠近更好。

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

• Git + GitHub 协作流程（Feature Branch + Pull Request + Code Review）
  从最初“直接 push 到 main”到后期严格执行 PR 审查机制，我们学会了如何在多人协作中安全、高效地集成代码。Code Review 不仅减少了低级错误，也促进了团队成员间的技术交流。
• SpringBoot（后端框架）
  相比传统 Flask，FastAPI 自动生成 OpenAPI 文档、内置 Pydantic 数据校验、异步支持等特性，让我们能快速构建健壮且文档完备的 RESTful API，前后端联调效率大幅提升。
• SpringAI
  接入大模型，让大模型赋能项目
• ApiFox + Swagger（API 调试与文档）
  借助 Swagger UI 自动生成的接口文档和 Postman 的集合管理，前后端对接不再依赖口头约定，接口变更也能及时同步，大幅减少联调摩擦。

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

• 团队协作与角色认知
  学会了在团队中找准自己的定位——有人擅长架构设计，有人精于细节实现，有人善于协调进度。
• 有效沟通能力
  从最初开会时各说各话，到后期能用流程图、接口文档清晰表达需求与方案，我们逐渐掌握了“工程师语言”：简洁、准确、可验证。尤其在跨前后端协作中，沟通效率显著提升。
• 时间管理与任务拆解能力
  面对复杂的项目目标，我们学会了将其拆解为可执行的小任务，并通过看板工具跟踪进度。
• 抗压能力与问题解决心态
  在 deadline 前遭遇关键 bug、演示前服务器宕机……这些“至暗时刻”没有击垮我们，反而让我们学会冷静分析、分工排查、快速回滚。
• 产品思维与用户意识
  不再只关注“功能是否实现”，而是开始思考：“用户会不会用？好不好用？有没有更好的交互路径？”
• 文档习惯与知识沉淀意识
  从一开始“代码即文档”，到后来坚持写 README、API 文档、部署指南，我们意识到：可维护的项目 = 可读的代码 + 完整的文档。
• 接受不完美，拥抱迭代
  曾经追求“一次性做对”，但现实教会我们：软件是在反馈中不断进化的。

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

如果用一句话总结这门课对我未来的影响，那便是：它让我从“会写代码的学生”，开始向“能交付价值的工程师”转变。
这学期的经历，坚定了我未来投身软件研发领域的决心——不是因为酷炫的技术，而是因为我享受“把想法变成可用产品”的全过程。

最有趣的课程片段？
是谁把数据库里的图片都换成梗图了！

最最最遗憾的事？
没有更早引入 UI/UX 设计思维。我们花了太多时间在“让功能跑起来”，直到后期才意识到体验的重要性。虽然最终做了补救，但若能从第一天就兼顾“可用”与“好用”，产品会更完整。

想对未来的 Z 班学弟学妹们说：

所有伟大的项目都始于一个粗糙的原型。
别怕和队友争论，真诚的碰撞才能打磨出更好的方案。

三、致谢

感谢 老师 在整个学期中的悉心指导。

更要感谢我的组员们：
谢谢你们在需求混乱时不抱怨，在 deadline 前不甩锅，在彼此写出“翻车”的代码时还能笑着一起重构。这门课让我知道，最好的技术，永远配得上最靠谱的队友。

轻舟已过万重山，而这段并肩作战的日子，我会一直记得。