课程总结

软件工程课程总结与反思

一、课程计划回顾与完成情况

在课程开始时，我制定了详细的学习计划，包括理论学习、实践项目、团队协作和技能提升四个方面。回顾整个学期，我的完成情况如下：

1. 理论学习（完成度：85%）

  • 目标：系统学习《构建之法》的核心内容，掌握软件工程的基本概念（如需求分析、设计模式、测试方法等）。
  • 实际完成：
    • 阅读了教材前8章，并整理了笔记，重点学习了敏捷开发、Scrum方法和软件测试策略。
    • 参与了课堂讨论，对“用户故事”“MVP（最小可行产品）”等概念有了更深刻的理解。
  • 未完成部分：
    • 原计划阅读完整本书，但由于项目开发占用时间，部分章节（如“软件维护”“配置管理”）未能深入研读。

2. 实践项目（完成度：90%）

  • 目标：完成一个完整的软件项目，涵盖需求分析、设计、编码、测试和部署。
  • 实际完成：
    • 团队成功开发了一个在线学习平台，采用前后端分离架构（React + Spring Boot）。
    • 实现了核心功能：用户注册/登录、课程管理、在线测试系统。
    • 使用了Git进行版本控制，并采用CI/CD（GitHub Actions）自动化部署。
  • 不足之处：
    • 由于时间限制，部分高级功能（如数据分析看板）未能实现。
    • 测试覆盖率仅达到70%，未达到预期的90%。

3. 团队协作（完成度：80%）

  • 目标：提升团队协作能力，学习项目管理工具（如Jira、Trello）。
  • 实际完成：
    • 团队采用Scrum方法，每周进行站会，并使用Jira管理任务。
    • 通过代码审查（GitHub PR）提升代码质量。
  • 遇到的问题：
    • 部分成员技术栈不匹配（如前端不熟悉React），导致初期进度较慢。
    • 沟通效率有待提高，部分需求变更未及时同步。

4. 技能提升（完成度：75%）

  • 目标：掌握新技术（如Docker、单元测试框架）。
  • 实际完成：
    • 学习了Docker容器化部署，成功将项目部署到云服务器。
    • 使用JUnit和Mockito编写了部分单元测试。
  • 未完成部分：
    • 原计划学习Kubernetes，但因时间不足未能深入。

二、对《构建之法》五个问题的回顾与回答

在课程初期，我提出了五个问题，现在尝试自己回答：

1. 问题：敏捷开发是否适用于所有类型的项目？

  • 回答：不完全适用。敏捷适合需求变化快的项目（如互联网产品），但对于高安全性、强监管的系统（如银行软件），传统瀑布模型可能更合适。
  • 课程是否帮助回答：是的，通过团队项目实践，我理解了不同开发模式的适用场景。

2. 问题：如何平衡代码质量和开发速度？

  • 回答：通过自动化测试（CI/CD）和代码审查可以在一定程度上兼顾，但有时必须做出取舍（如MVP阶段可适当降低测试覆盖率）。
  • 课程是否帮助回答：部分帮助，但实际项目中仍感到矛盾。

3. 问题：软件工程师的“技术深度”和“业务理解”哪个更重要？

  • 回答：取决于角色。架构师需要技术深度，而产品经理更需要业务理解。但优秀的工程师应兼具两者。
  • 课程是否帮助回答：课程更侧重技术实践，业务理解较少涉及。

4. 问题：如何有效管理技术债务？

  • 回答：定期重构、编写测试用例、文档化关键设计决策。
  • 课程是否帮助回答：项目后期我们确实遇到了技术债务问题，但课程未系统讲解应对策略。

5. 问题：软件工程是否过度依赖工具？

  • 回答：工具能提升效率，但核心仍是设计思维和问题解决能力。
  • 课程是否帮助回答：通过使用Git、Jira等工具，我理解了其必要性，但也意识到不能迷信工具。

未能完全回答的问题：

  • 问题3和4涉及长期工程实践，课程时间有限，难以深入。

三、新产生的问题

  1. 如何评估团队项目的“成功”？

    • 除了功能完成度，是否应考虑代码质量、用户反馈、可维护性？
    • 建议：引入更多量化指标（如SonarQube代码分析、用户满意度调查）。

  2. 学生团队如何模拟真实企业的开发压力？

    • 课程项目时间宽松，而企业往往面临严格 deadline。
    • 建议：设置“高压冲刺”环节（如限时修复线上Bug）。

  3. 软件工程伦理问题如何融入教学？

    • 如数据隐私、AI伦理等，课程未涉及。
    • 建议：增加相关案例讨论。

四、文献回顾与“事后诸葛亮”分析的新感想

在团队进行项目复盘时，我们发现：

  • 需求分析不足：初期未充分调研用户，导致后期频繁修改。
  • 测试被忽视：因赶进度，测试阶段压缩，导致线上Bug频发。
  • 沟通成本高：异步协作（如文档更新不及时）导致信息不同步。

新感想：

  • 文档的价值：初期认为“敏捷=少文档”，但后来发现关键设计仍需记录。
  • 技术选型的容错性：应优先选择团队熟悉的技术，而非盲目追求新技术。

五、技能提升与不可量化的收获

可衡量的提升

技能 课前水平（1-5） 课后水平（1-5）
Git协作 2 4
单元测试 1 3
系统设计 2 4

不可量化的收获

  • 工程思维：学会从“写代码”转向“做产品”。
  • 团队协作：如何平衡个人贡献与团队目标。
  • 抗压能力：在 deadline 前高效工作的技巧。

六、对课程的未来建议

1. 教学方法

  • 增加企业案例：邀请工程师分享真实项目经验（如失败案例）。
  • 模拟真实环境：引入“客户角色”，由助教扮演需求方，增加沟通挑战。

2. 与其他课程的衔接

  • 前置技能强化：在课程初期加入“Git实战”“API设计”等 Workshop。
  • 跨课程协作：与数据库、前端课程联动，避免知识断层。

3. 对助教的建议

  • 更频繁的代码审查：目前仅期末一次，建议中期增加1-2次。
  • 个性化反馈：针对不同团队的技术栈提供定制化建议。
posted @ 2025-06-04 21:53  李蕊lr  阅读(13)  评论(0)    收藏  举报