软件工程实践总结——回顾与思考

[222200228曹伟]

这个作业属于哪个课程	FZU_SE_teacherW_4
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	总结软工实践与个人技术的收获
其他参考文献	《构建之法》

---

目录

• 1.课程回顾与总结
• 1.1 原问题链接
• 1.2 再次思考以前的问题
• 1.2.1 代码量与个人的编码能力有直接关系吗
• 1.2.2 应该在什么时候使用goto
• 1.2.3 花费时间越多，代表工作量越高吗
• 1.2.4 “技能”比“解决问题”更重要吗？
• 1.2.5 个人在团队中的角色就像是一个流水线上的机器吗？
• 1.3 是否原来的问题还不明白？
• 1.4 是否产生了新的问题？
• 1.5 每个阶段收获最大的知识或能力
• 1.5.1 需求阶段
• 1.5.2 设计阶段
• 1.5.3 实现阶段
• 1.5.4 测试阶段
• 1.5.5 发布阶段
• 1.6 结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得
• 1.6.1 个人项目
• 1.6.2 结对编程
• 1.6.3 团队项目
• 1.7 自我评分
• 2.个人技术总结
• 2.1 个人技术博客链接
• 2.2 概述
• 3.软件开发模式
• 3.1 项目开发过程
• 3.1.1 项目目标
• 3.1.2 主要技术栈
• 3.1.3 关键决策
• 3.1.4 遇到的挑战及解决方案
• 3.1.4.1 初期设计的数据库与实际上需要使用的有一定出入
• 3.1.4.2 在不同设备上我们的界面可能显示不同
• 3.2 软件开发模式的思考
• 3.2.1 所采用的软件开发模式
• 3.2.2 敏捷开发模式的优缺点及其影响
• 3.2.3 对比不同软件开发模式
• 3.2.4 场景下的开发模式建议
• 3.2.5 我的理解和建议

1.课程回顾与总结

1.1 原问题链接

原问题链接

1.2 再次思考以前的问题

1.2.1 代码量与个人的编码能力有直接关系吗

代码量在一定程度上能够反映一个人的代码熟练度，但是不成严格的正相关，有效代码量的积累可以提升个人的编码能力

1.2.2 应该在什么时候使用goto

对于goto语句，我还是保持原有的看法：尽量不使用goto语句，goto语句会使代码结构混乱，可读性也很差

1.2.3 花费时间越多，代表工作量越高吗

不一定，经过软工实践的亲身体验，我发现即使在一项比较简单的任务中，也可能因为粗心大意脑袋不清醒写出bug，而排查这个bug可能会花费远比编写这个程序本身多得多的时间，我认为花费时间越多，不一定代表工作量越高，编码时一定要保持清醒

1.2.4 “技能”比“解决问题”更重要吗？

我还是这么认为：二者是相辅相成的，技能服务于解决问题，解决问题需要技能支持。解决问题是我的最终目标，而掌握相应的技能能够使我更快更准确地达到解决问题的目的

1.2.5 个人在团队中的角色就像是一个流水线上的机器吗？

我不这么认为，每个人都有自己擅长的领域以及个性，队员间的互动能够很大程度上影响项目的开发，这和机器有本质上的区别，在本次实践中我认识到，队员间的沟通与配合有时甚至要重要过编码本身

1.3 是否原来的问题还不明白？

都明白了

1.4 是否产生了新的问题？

如何解决组员参与不积极的问题
如何解决组员间的衔接与配合问题

1.5 每个阶段收获最大的知识或能力

1.5.1 需求阶段

• 需求分析与沟通能力：掌握与各方stakeholder有效沟通的技巧，准确捕捉和理解用户需求。
• 需求文档与管理能力：学会将需求转化为清晰、结构化的文档，并能够有效管理需求变更。

  1.5.2 设计阶段

• 系统架构设计能力：能够设计可扩展、可维护的系统架构，并进行合理的技术选型。
• 模块设计与抽象能力：学会将复杂需求抽象为清晰的模块设计，定义良好的接口和交互。

  1.5.3 实现阶段

• 版本控制与协作开发：熟练使用版本控制工具，具备团队协作开发的能力。
• 高质量编码能力：掌握编码规范和最佳实践，能够编写高效、可维护的代码。
• 调试与问题解决能力：能够高效定位和解决代码中的问题，提高开发效率。

  1.5.4 测试阶段

• 测试设计与自动化能力：学会设计全面的测试用例，并实现自动化测试。
• 质量保证意识：培养对软件质量的敏感度，能够从多角度保证产品质量。

  1.5.5 发布阶段

• 部署与运维能力：掌握软件部署、配置和监控的技能，确保系统稳定运行。
• 持续优化与迭代能力：基于用户反馈和监控数据，持续改进产品和开发流程。

  1.6 结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得

  1.6.1 个人项目

  在个人项目中，我认识到了自己对项目各个阶段完成时间把握的不恰当，以及对整个开发框架部署的不够完善导致项目整体打满补丁；项目各个任务的完成度也不够高，对开发工具的使用不够熟练；重要的一点是对单元测试的编写一无所知，但是自己能够全盘把握项目的进度，使用自己想用的技术栈，这点比较方便

  1.6.2 结对编程

  结对编程的一个优点就是：在其中一个程序员负责编码时，另一个程序员在一旁监督，实现高效的纠错，大大减少修复bug花费的时间。同时两个程序员面对一台主机进行开发的方式也大大提供了队员间的沟通效率，有什么问题与疑惑可以当场交流并解决，能够实时得到反馈。当然，在双方意见不一致时，需要采取正确的策略来达到统一意见。

  1.6.3 团队项目

  在团队项目中，我切实地感受到了分工合作、沟通以及队员间任务衔接的重要性，你需要沟通来了解各个队员的工作情况和代码详情，再考虑如何实现任务时也需要和协作者沟通交流，也需要采用合理的分工来给每个队员分配合适的任务，队员间任务的衔接也是至关重要的，总之，在这次团队项目中，我学会了很多东西，不仅有如spring boot，html与css，云端部署数据库这样的硬技术的习得，还有如团队合作，沟通交流，抗压能力等在实际软件开发中不可或缺的能力的锻炼，不仅如此，在本次项目中还巩固了往先习得的如java，mysql，uml等知识，对各种警告，报错的原因也逐渐熟悉，最重要的是，本次实践让我真切地感受了软件开发的流程，让我受益匪浅

  1.7 自我评分

• 目标1：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念
  评分：80分
  这一目标中，我理解并铭记了软件工程师的职业道德规范和实践要求，也在一定程度上了解了软件产品对社会、健康文化等影响，树立了积极向上的软件开发理念，但是在了解国情社情民情方面上还有所欠缺，对社会的大环境理解还不够透彻
• 目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型
  评分：85分
  关于需求分析，我已基本能够辨别客户表述的多样化需求，能够较为熟练的使用xp等原型工具，够规范、准确地表达客户的需求，构建需求分析模型，并根据客户需求的变化作出准确的调整
• 目标3：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案
  评分：80分
  我以及能够基本掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，但是队员构建级设计模型，我的构建能力还有所欠缺
• 目标4：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案
  评分：70分
  我对设计模型的评判能力还是有所欠缺，没办法比较精确地对模型进行评估，创新意识较差
• 目标5：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力
  评分：80分
  对于软件开发各阶段文档，我能够根据标准，采用规范的表达编写，并基本掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，已经大致具备了与业界同行的交流能力
• 目标6：具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作
  评分：75分
  对于团队协作方面，我还是有所欠缺的，在开发初期具有良好的团队意识，能够积极组织、协调或指挥团队开展工作，积极参与队员间的沟通交流，但是随着开发的进行，我开始逐渐对某些成员的不负责任开始不耐烦，生闷气
• 目标7：能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力
  评分：85分
  对与项目管理的基本要素和工具，我有基本的了解，也已经掌握了如何进行项目规模和工作量估算。但在实践中，我还没有深入参与过复杂项目的管理工作，能够使用一些基本工具来规划进度，但在复杂项目管理中仍然显得比较局促。

  2.个人技术总结

  2.1 个人技术博客链接

  个人技术博客——spring boot

  2.2 概述

  Spring Boot 是基于 Spring 框架的快速开发框架，旨在简化 Spring 应用的开发过程。它的核心优势在于 简化开发、提高效率，同时提供了生产级的功能和灵活的扩展性，是现代 Java 应用开发的首选框架。它特别适合快速开发和部署微服务架构的应用。

  3.软件开发模式

  3.1 项目开发过程

  3.1.1 项目目标

  创建一个用户友好且功能丰富的个人健康管理系统，支持用户记录和管理日常健康数据（如体重等），提供个性化健康建议，同时实现运动记录和设备管理功能。

  3.1.2 主要技术栈

• 前端：纯HTML5 + CSS3 + JavaScript用于构建用户界面，确保良好的用户体验。
• 后端：Spring Boot作为核心框架，提供了强大的依赖注入、自动配置和生产就绪特性，简化了Java应用的开发。
• 数据库：采用关系型数据库MySQL，具有跨平台兼容性强、支持多种编程语言、安全性高且具备良好的可扩展性。
• 其他工具：Maven等工具

  3.1.3 关键决策

• 选择SpringBoot作为开发框架：Spring Boot提供了快速开发、自动配置、内嵌服务器、简化依赖管理的特性，大大提高了Java应用开发效率，同时保持了高度的灵活性和可扩展性。
• 项目管理：再考虑人员问题以及现有资源后，选择削减一部分功能来达到精简项目的目的

  3.1.4 遇到的挑战及解决方案

  3.1.4.1 初期设计的数据库与实际上需要使用的有一定出入

  解决方案：按需调整数据库表，删去多余无用的字段，优化范式

  3.1.4.2 在不同设备上我们的界面可能显示不同

  解决方案：采用响应式Web设计原则，确保网页在各种屏幕尺寸上都能良好展示。

3.2 软件开发模式的思考

3.2.1 所采用的软件开发模式

本项目采用敏捷开发的开发模式，通过迭代式开发、持续反馈和团队协作的方式，能够快速响应需求变化，提高开发效率和产品质量，同时降低项目风险并确保交付价值最大化。

3.2.2 敏捷开发模式的优缺点及其影响

• 优点：

1.灵活性和适应性：能够快速响应需求变化，适应市场和客户需求的快速变化
2.持续交付和快速反馈：频繁的迭代和发布，及时获取用户反馈，快速调整方向
3.日常站会促进沟通，跨职能团队协作，减少沟通障碍

• 缺点：

1.文档相对较少：可能影响长期维护，对新加入团队成员的学习曲线较陡
2.可能忽视整体设计：过于关注短期目标，可能忽视长期架构考虑
3.团队压力可能较大：持续的快节奏开发可能导致团队倦怠

3.2.3 对比不同软件开发模式

• 瀑布模型 vs 敏捷开发：瀑布模型是线性顺序的、计划驱动的开发方法，强调前期详细规划和文档；而敏捷开发是迭代式的、适应性强的方法，注重频繁交付、持续反馈和灵活应对变化。
• 增量模型 vs 敏捷开发：增量模型是按功能模块逐步完成系统开发，每个增量都是完整可用的，但仍保持较为固定的计划和流程；而敏捷开发更强调适应性和灵活性，通过短期迭代持续交付价值，并随时响应变化。

  3.2.4 场景下的开发模式建议

• 传统企业级应用：适合采用瀑布模型或增量模型，因为这类项目通常需求明确、变更少、安全性要求高，需要完整的文档和严格的流程控制。
• 创新型互联网产品或初创企业的项目：最适合采用敏捷开发模式，因为需要快速验证市场、频繁迭代、及时响应用户反馈，并能够灵活调整产品方向。
• 大型在线服务平台：适合采用混合模式（敏捷+DevOps），结合敏捷的灵活性和持续交付，同时保持架构的稳定性和可扩展性，确保服务的可靠性和性能。

  3.2.5 我的理解和建议

  选择合适的软件开发模式是项目成功的关键因素之一，它需要我们全面考虑项目特性、团队能力和业务需求。对于个人健康管理系统这类需求多变、用户体验至关重要的项目，敏捷开发模式确实是一个优秀的选择。敏捷方法不仅能够促进团队协作，快速响应用户需求变化，还能通过持续迭代提升产品质量和竞争力。然而，我们也应该认识到，没有一种开发模式能够适用于所有场景。在未来的工作中，我们需要保持开放和灵活的态度，根据不同项目的具体情况，可能采用纯粹的敏捷方法，或者将敏捷与其他方法（如瀑布模型、增量模型或DevOps）相结合，创造出最适合当前项目的混合开发模式。这种灵活性和适应性将帮助我们更好地应对各种复杂的开发场景，最大化项目成功的机会。