软工实践团队总结

一、学期回顾
1.1 回顾你对于软件工程课程的想象
最初我以为软件工程只是 “写代码做项目”，直到实践课程开始才明白，它真正的核心是「工程化思维」：如何把一个模糊的想法，变成可落地、可维护、可迭代的软件。我的目标是做一个能真正帮到玩家的三角洲助手，过程中确实达成了功能开发的目标，但也暴露出很多不足：比如一开始只关注功能实现，忽略了 API 超时、数据持久化这些 “看不见的工程问题”，导致助手频繁离线，可用性大打折扣。
1.2 回顾你在这门课程中的投入与产出
个人代码贡献：累计编写约 1200 行 Java 代码，主要负责 AI 问答模块、数据库连接模块和攻略数据持久化逻辑。
项目角色：核心开发与架构设计，负责火山方舟 API 对接、MySQL 数据库设计与业务逻辑改造。
时间投入记录：

作业	花费时间
第一次团队作业	4 小时
第二次团队作业	6 小时
第一次团队项目作业	8 小时
第二次团队项目作业	12 小时
第三次团队项目作业	15 小时
第四次团队项目作业	18 小时

课程累计时间：
累计时间：63 小时
实际周均时间：7 小时
预计周均时间：5 小时
1.3 令你印象最深刻的一次作业 / 答辩
印象最深的是beta 冲刺阶段，当时助手频繁出现 API 超时、离线模式无法使用的问题，用户提问只会提示 “连接超时”，无法返回任何有效内容。我花了整整两周时间排查问题，从代理配置、请求线程到数据库降级逻辑，一步步定位到是 Java 程序自动读取系统代理导致的链路阻塞，最终通过强制直连 + 数据库优先的方式解决了问题。这次经历让我明白，软件的 “稳定性” 和 “可用性”，比单纯的功能实现更重要。
二、总结收获
2.1 软工实践故事：从 “离线助手” 到 “永不离线”
我的项目是《三角洲行动合规游戏助手》，核心功能是为玩家提供地图攻略、阵容打法和配装建议。
初期困境：alpha 冲刺阶段，助手完全依赖火山方舟 API 调用，一旦网络波动或代理链路异常，就会进入离线模式，用户提问无响应，攻略也无法查看，用户体验极差。
关键突破：beta 冲刺中，我引入了 MySQL 数据库，设计了「game_strategies」攻略表，实现了 “数据库优先、API 兜底” 的降级逻辑：用户提问时，优先从数据库检索对应攻略，命中则直接返回；无匹配内容时再调用 AI 生成，并自动将新攻略写入数据库。同时修复了 Java 自动代理导致的 API 超时问题，强制直连火山方舟服务器，彻底解决了离线问题。
最终成果：现在助手即使 API 超时，也能正常返回已保存的攻略内容，稳定性和可用性提升了 100%，真正实现了 “永不离线” 的战术助手。
2.2 学到的新技术与生产力工具
MySQL 数据库设计与索引优化：学会了根据业务场景设计表结构，通过联合索引（category + map_name）大幅提升攻略检索速度，解决了数据读取卡顿的问题。
Java 网络请求深度调试：掌握了 HTTP 请求的底层原理，学会了配置连接超时、读取超时，关闭系统代理，避免 Java 自动代理导致的请求异常。
Cursor AI 辅助开发：学会了用 AI 工具批量生成、调试代码，快速定位 API 调用、线程阻塞等问题，大幅提升了开发效率。
软件工程降级设计思想：明白了 “主逻辑 + 降级方案” 的重要性，不再把 API 当作唯一依赖，而是通过数据库持久化，实现了服务的高可用。
2.3 技术之外的提升
问题排查能力：从只会 “报错就百度”，到能通过日志、抓包、分步测试定位 API 超时、线程阻塞等复杂问题，解决问题的思路更清晰了。
工程化思维：写代码不再只关注 “能不能跑”，而是会考虑 “跑崩了怎么办”“网络不好怎么办”“用户量大了怎么办”，学会了从用户体验和稳定性的角度思考问题。
耐心与韧性：面对 API 超时、代理配置等反复出现的问题，学会了沉下心一步步排查，而不是直接放弃或躺平。
2.4 想记录的话
这门课让我明白，软件工程不是一蹴而就的魔法，而是无数次调试、重构和优化的过程。从一开始的 “功能跑起来就行”，到后来追求 “稳定、高效、可用”，我对 “做软件” 这件事有了完全不同的理解。未来我还想把这个助手做成微信小程序，对接官方数据接口，让更多玩家能用上这个工具。也想对学弟学妹说：别害怕 bug，每一个 bug 都是你成长的机会，把每一次调试都当成一次学习，你会走得比想象中更远。
三、致谢
特别感谢我的课程老师和舍友同学，在项目遇到瓶颈时给了我很多关键的指导；也感谢我的同学，在我遇到难题时帮我一起排查问题，一起讨论方案。正是你们的帮助，让我能坚持把项目做完，并且真正解决了核心问题。