软件工程实践总结——构建与反思

[222200324郑昱]

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

目录

• 一、 课程回顾与总结
• 1.1 原问题思考链接
• 1.2 再次解答以前的问题
• 问题1： 我都是大学生了，上课还要认真听老师讲课么？
• 问题2：在项目或程序比较复杂的情况下，如何高效率的进行程序理解？
• 问题3：有了GPT类的应用，传统的搜索引擎是否会被完全替代？
• 问题4：单元测试与自动测评机相比有何优劣，能否在一定条件下被替代，或者说互补？
• 问题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 自我评分
• 目标1：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念
• 目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型
• 目标3：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案
• 目标4：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案
• 目标5：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力
• 目标6：具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作
• 目标7：能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力
• 二、 个人技术总结
• 2.1 个人技术博客链接
• 2.2 概述
• 三、软件开发模式
• 3.1 项目开发过程
• 3.1.1 项目目标
• 3.1.2 主要技术栈
• 3.1.3 关键决策
• 3.1.4 遇到的挑战与解决方案
• 3.2 软件开发模式的思考
• 3.2.1 分析所采用的软件开发模式

一、 课程回顾与总结

1.1 原问题思考链接

原问题思考链接

1.2 再次解答以前的问题

问题1： 我都是大学生了，上课还要认真听老师讲课么？

课堂能提供系统性知识、节省学习时间、培养思维能力。如果只是因为懒得听，可能会影响长期成长。很多课程不仅是知识传授，还涉及思维训练，比如数学、算法、工程实践等，认真听课有助于掌握老师的思考方式。

问题2：在项目或程序比较复杂的情况下，如何高效率的进行程序理解？

高效理解复杂程序的关键在于先宏观后微观，先阅读后实践。首先分析整体架构，查看文档、目录结构和关键流程，明确核心逻辑。然后按模块拆解代码，理解数据流向，并利用 IDE 搜索、调试工具、日志分析等手段加速理解。通过运行测试、修改代码观察变化、绘制流程图等方式加深理解，同时查阅文档、请教他人，提高学习效率。这样可以快速掌握代码逻辑，提升开发效率。

问题3：有了GPT类的应用，传统的搜索引擎是否会被完全替代？

GPT 类应用虽然提升了信息获取的效率，但短期内不会完全取代传统搜索引擎，而是与之互补。GPT 擅长自然语言交互、信息总结和代码生成，而搜索引擎在实时性、权威性和专业内容获取上更具优势。未来，搜索引擎可能会融合 AI 技术，提供更智能的对话式搜索，但传统网页索引仍然不可或缺。因此，GPT 可能替代部分问答和内容总结场景，但搜索引擎仍将在全面信息检索中发挥重要作用。

问题4：单元测试与自动测评机相比有何优劣，能否在一定条件下被替代，或者说互补？

单元测试专注于代码内部逻辑，验证函数或模块的正确性，而自动测评机主要用于评测整个程序的输入输出，常见于竞赛和作业评测。单元测试可以发现边界情况和异常处理问题，而自动测评机适用于大规模评测但难以检查代码内部实现。二者不能完全替代，而是互补关系，在软件开发中可以结合使用，如单元测试保障代码质量，自动测评机用于回归测试或大规模代码评测，以提升整体可靠性和效率。

问题5：如果在扩展功能时发现接口设计错误或考虑不周应该怎么办？

当扩展功能时发现接口设计存在错误或考虑不周，应首先评估问题的影响范围，判断是局部调整还是需要整体重构。对于轻微问题，可以通过版本迭代、小范围修改或增加兼容性适配层来解决；对于影响较大的设计缺陷，应及时与团队沟通，制定合理的优化方案，确保新设计兼容旧版本，并减少对现有系统的影响。同时，完善文档和测试，避免类似问题再次发生，确保接口的长期可维护性和可扩展性。

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

没有不明白的

1.4 是否产生了新的问题？

如何实现高效的团队协作与沟通？
如何有效进行软件性能优化？

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

1.5.1 需求阶段

• 需求分析与沟通能力：在需求阶段，你学习如何与客户、用户、产品经理等各方沟通，明确需求并确保理解一致。这有助于你更好地捕捉并整理用户的实际需求，避免误解。
• 需求文档编写：掌握如何将需求转化为清晰的文档，包括功能需求、非功能需求和约束条件，确保项目有明确的目标和可执行的任务。
• 问题解决思维：通过需求分析，学会将模糊的问题具体化，拆解为可实现的功能点，确保开发过程中的目标明确。

1.5.2 设计阶段

• 架构设计与系统建模能力：在设计阶段，你学习如何设计可扩展、可维护的系统架构，使用 UML 图等工具进行系统建模。这能够帮助你理解如何设计复杂系统及其模块之间的关系。
• 技术选型能力：学会根据项目需求选择合适的技术栈和框架，评估不同技术方案的优劣。
• 问题抽象与分解能力：学习如何将复杂的业务需求抽象为具体的模块或组件，设计模块之间的接口，确保系统设计高效、清晰。

1.5.3 实现阶段

• 编码能力与最佳实践：通过实现阶段，你提高了编写高效、可维护代码的能力，掌握了编码规范、常见设计模式及其应用。
• 版本控制与协作开发：在团队协作中使用 Git、SVN 等工具进行代码管理，学习如何高效地进行代码合并、分支管理和冲突解决。
• 调试与问题定位：学会使用调试工具定位和修复代码中的bug，提高代码质量。

1.5.4 测试阶段

• 测试设计与自动化测试能力：在测试阶段，你学习如何设计有效的测试用例，进行单元测试、集成测试、系统测试和验收测试。
• Bug 分析与修复能力：提高了识别问题和解决问题的能力，通过测试反馈和修复，学会如何确保软件的质量和稳定性。
• 持续集成与测试自动化：通过配置 CI/CD 流程，实现自动化测试和部署，确保开发过程中的代码始终处于可交付状态。

1.5.5 发布阶段

• 部署与发布管理能力：学习如何将软件从开发环境迁移到生产环境，进行部署、发布、配置和监控。
• 性能优化与监控：通过发布阶段，掌握了如何监控系统的性能，优化系统的响应速度、负载均衡等，确保系统稳定运行。
• 用户反馈与迭代能力：通过收集用户反馈和监控数据，学会如何快速迭代和调整功能，持续改进产品。

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

1.6.1 个人项目

在个人项目中，我能够全权负责项目的各个环节，从需求分析到设计、实现、测试和发布，培养了独立思考和自我驱动的能力。最大收获是学会如何从零开始规划一个项目，如何在遇到技术难题时进行自我学习和调试，并解决实际问题。这种自主性让我更深入理解了每一个开发环节的重要性。同时，我也学会了如何进行时间管理和任务优先级的安排，以确保项目按时完成。
独立项目有助于自我提升，但也容易陷入“完美主义”，导致进展缓慢。在个人项目中，我学会了如何权衡“功能完成”与“代码质量”，找到更高效的开发方式。

1.6.2 结对编程

结对编程是一种高效的协作方式，它让我在与同伴的互动中更快速地发现问题并改进自己的代码。在结对编程中，我不仅能从另一个开发者那里学到不同的编程技巧和思路，还能得到实时的反馈和建议，这极大地提高了我的编程效率和代码质量。通过这种方式，我也体会到了代码分享和合作思维的重要性。
结对编程强调即时反馈，能有效提升代码质量并减少错误，但也需要双方保持良好的沟通。遇到意见不一致时，如何通过讨论达成共识是提高效率的关键。

1.6.3 团队项目

在团队项目中，我体会到了良好沟通和合理分工的重要性。与团队成员的协作不仅仅是代码的整合，更是如何充分理解各自的职责和优势，从而有效分配任务。团队项目中，最大收获是学会了如何进行任务管理与团队协调，如何通过使用工具（如 Git、JIRA、Trello 等）进行进度追踪和问题跟踪。此外，代码评审和集体讨论也是团队项目中不可或缺的部分，团队成员通过定期的代码审查和技术讨论，能够提高整体项目质量。
团队项目最大的挑战之一是协调每个人的工作节奏和任务优先级，特别是在需求变更时，如何灵活调整并确保项目顺利推进是关键。团队中的每个成员都需要具备较强的沟通和协作能力，团队的成功依赖于每个人的责任感和配合度。

1.7 自我评分

目标1：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念

评分：85分

在这一目标中，我理解了软件工程师的职业道德及其对社会和文化的影响，学习了如何将社会责任融入软件开发过程。然而，尽管有了基础的认识，实际如何在开发中应用这些道德标准和影响力仍需进一步实践。对于软件对社会、文化、健康的深远影响，还需要更多的案例分析和讨论。

目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型

评分：80分

在需求分析方面，我对如何通过与客户沟通收集需求以及用规范的工具进行表达有了较为清晰的理解，但在实践中，我还需要更多的机会去锻炼自己的需求建模能力，并深入理解如何准确地从多样化的客户需求中提炼出核心需求。

目标3：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案

评分：75分

在软件开发的全过程中，我熟悉了体系结构设计方法和基本设计原则，但对于从整体架构到数据、构件级别的设计，我的掌握还不够深入。在课堂学习中，通过实际的项目案例，我能理解和参与设计过程，但还缺乏较为独立的设计经验。

目标4：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案

评分：70分

在技术评测方面，我了解了如何从组件到系统进行技术评估，但在实践中我还没有进行过较为深入的设计方案选择和评测工作。虽然课堂上学习了设计评判的理论，但如何在复杂项目中应用创新设计意识，仍是一个挑战。

目标5：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力

评分：85分

在文档撰写方面，我已经较为熟悉需求规格说明书、设计说明书、测试报告等的格式和规范表达。课堂上通过多次练习，我掌握了如何使用清晰、规范的语言撰写文档，并且能够与同学进行有效的交流与分享。但与业界同行的交流能力还需要通过更多实际项目进行锻炼。

目标6：具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作

评分：90分

在团队项目和结对编程中，我锻炼了自己的团队合作与沟通能力。在项目中，我积极参与团队的讨论，能够与其他成员协调合作，促进项目的顺利进行。虽然我还在不断提升自己的领导能力和组织协调能力，但已经能够有效地协作和推动团队工作。

目标7：能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力

评分：75分

我对项目管理的基本要素和工具有一定的了解，掌握了如何进行项目规模和工作量估算。但在实践中，我还没有深入参与过复杂项目的管理工作，虽然能够使用一些基本工具来规划进度，但在复杂项目管理中的经验仍显不足。

二、 个人技术总结

2.1 个人技术博客链接

个人技术博客——从Vue到前后端协作：项目开发中的技术探索与解决方案

2.2 概述

Vue 是一个用于构建现代 Web 应用的前端框架。它以其简洁的语法和强大的响应式机制在前端开发中占有一席之地。本项目中，我通过学习并应用 Vue.js，成功将前端与后端的交互做得更加流畅，解决了数据绑定、组件化开发、接口调试等技术难题。

三、软件开发模式

3.1 项目开发过程

3.1.1 项目目标

该项目的目标是设计并实现一个学习资源共享和课程评价系统，重点在于系统架构设计和数据库设计。系统将提供课程展示、评价提交、资源上传和下载、数据统计等功能，旨在提高大学生学习资源的获取效率，并通过课程评价功能帮助学生和教师获取更好的反馈。

3.1.2 主要技术栈

1. 前端：Vue.js，主要负责用户界面的开发，提供响应式设计和交互效果。
2. 后端：Spring Boot，处理系统的业务逻辑和数据存储，支持RESTful API进行前后端通信。
3. 数据库：MySQL，设计合理的数据表结构，确保数据关系的完整性和高效查询。
4. 容器化部署：Docker，确保模块间的独立性与可扩展性。
5. CI/CD：通过持续集成与持续部署工具，提高开发效率和代码质量。

3.1.3 关键决策

1. 前后端分离架构：选择Vue.js和Spring Boot进行前后端分离设计，确保系统的扩展性和维护性。
2. 数据库设计：使用MySQL，并根据系统功能设计合理的ER图和数据库表结构，确保数据关系的完整性。
3. 容器化部署：使用Docker进行模块化部署，保证各个模块的独立性并便于版本管理。

3.1.4 遇到的挑战与解决方案

1. 项目管理的挑战：

   • 挑战：项目管理中，部分任务的时间安排不合理，导致资源浪费和进度拖延；同时，部分成员的任务负载不均，影响了团队的整体效率。

   • 解决方案：优化项目进度安排，合理分配资源，确保任务之间的优先级明确。通过使用敏捷开发方法，分阶段进行任务管理，定期评估项目进度，及时调整计划。同时，采用任务追踪工具（如JIRA、Trello）对团队成员的任务进行监控，确保负载均衡并按时完成任务。

2. 前后端接口协调的挑战：

   • 挑战：前后端接口的设计与实现存在不一致或沟通不畅的问题，导致开发进度滞后和功能不匹配。

   • 解决方案：建立前后端联调流程，确保接口文档的准确性和完整性。通过定期的前后端沟通会议，及时解决接口设计和实现过程中出现的问题。此外，可以使用API文档生成工具，确保接口的一致性和规范性，减少开发中的沟通成本。

3. 技术能力不足的挑战：

   • 挑战：项目中的部分成员技术能力不足，导致任务进度滞后，影响整体进度。

   • 解决方案：通过针对性的技术培训、学习资源共享和团队内部的技术交流，提升团队成员的技术能力。此外，可以采用结对编程、代码复审等协作方式，加强成员之间的技术互动和支持，确保项目按时推进。

3.2 软件开发模式的思考

3.2.1 分析所采用的软件开发模式

在我参与的项目中，我们采用了敏捷开发模式，特别是Scrum框架。这个开发模式对于我们的团队和项目的需求非常适合，但也伴随着一些挑战。以下是我对这种模式的分析、优缺点及适用场景的思考。

1. 敏捷开发模式分析
   敏捷开发是一种强调快速响应变化、灵活适应客户需求和频繁交付的软件开发方法。它通常采用迭代式开发，将一个大型项目分解为多个小的可交付的迭代单元（Sprint），每个迭代周期通常为1至2周。

• 优点：
  • 快速响应变化：敏捷开发非常注重用户反馈和需求变化，我们能够在每个迭代周期结束时与客户沟通，确保开发的功能符合实际需求。
  • 提高团队协作：敏捷强调团队内部的沟通和协作，每日立会（Daily Standup）让团队成员及时了解进度，消除潜在问题。
  • 持续交付价值：每个迭代结束时都会交付一个可工作的软件版本，能够确保项目有持续的产出，并提高客户的满意度。
  • 提高项目透明度：通过任务看板、Burndown图等工具，团队可以清楚地了解每个迭代的进度，管理者也能随时掌握项目情况。
• 缺点：
  • 前期规划不足：由于敏捷强调灵活性和响应变化，可能导致项目初期的规划和设计不够详尽，进而影响项目的整体方向。
  • 可能的资源浪费：由于每个迭代需要快速交付功能，如果需求变更频繁，开发过程中可能会有部分功能开发了却未最终使用，造成资源浪费。
  • 管理复杂性增加：在大规模团队中，敏捷开发要求高度的自组织和自主性，管理者需要投入更多精力进行协调，确保项目进展顺利。
  • 团队依赖性强：敏捷要求团队成员具有较高的协作和沟通能力，若团队中成员技能不均或沟通不畅，会影响项目进度。

2. 敏捷开发模式对项目开发效率、团队协作和最终交付的影响

• 开发效率：敏捷开发模式通过短周期的迭代，使得开发进度更加可控，同时对需求的灵活调整也提高了开发效率。开发人员不需要等待长时间的需求冻结，而是能在每个迭代周期中做出调整，及时发现并解决问题。

• 团队协作：敏捷非常强调团队协作，每日立会、Sprint回顾等环节促使团队成员之间的沟通更加频繁和有效。团队成员能够在较短时间内及时解决问题，确保项目的顺利推进。

• 最终交付：通过持续交付和短迭代周期，敏捷开发能确保项目逐步交付高质量的可用功能。而且，灵活的调整机制也能让项目更贴近用户的实际需求，提升最终交付的质量和客户满意度。

3. 对比不同软件开发模式

• 瀑布模型：瀑布模型强调的是线性阶段性开发，从需求分析到设计、实现、测试和维护，逐步推进。适合需求固定且变化较少的项目，但在需求变动频繁或不明确的情况下，瀑布模型的适应性差，开发进度容易受到影响。

• DevOps：DevOps是一种结合开发和运维的模式，旨在通过自动化和持续集成（CI）/持续交付（CD）提高开发和运维的效率。它适合于需要高频次发布、快速反馈的项目，特别是对基础设施和软件发布过程有严格要求的产品。

选择合适的开发模式

• 瀑布模型适合的场景：项目需求相对固定且明确，变化较少的环境。例如：传统企业的财务软件、银行系统等，需求大多是清晰的、长期不变的。
• 敏捷开发适合的场景：需求变化频繁、客户反馈周期短、开发过程中不确定性较大的项目。例如：互联网产品、移动应用开发等，需要根据市场反馈快速调整的项目。
• DevOps适合的场景：对软件发布有高频次、低风险要求的项目，如云计算平台、SaaS产品等。

4. 软件开发模式选择的思考与建议
   在选择开发模式时，我认为最重要的还是结合项目的实际需求和团队的特点来做决定。以下是我个人的一些建议：

• 了解需求和变化程度：如果需求明确且不会大幅变动，瀑布模型可能更合适；如果需求不确定且客户反馈频繁，敏捷开发会更适合。
• 团队规模与协作：敏捷开发对团队协作要求较高，适合小团队或有较高协作精神的团队。如果团队成员分散或者缺乏足够的沟通，可能需要花更多时间进行协调。
• 技术栈与工具支持：采用敏捷开发时，团队需要有合适的工具（如JIRA、Trello、Git等）来支持项目管理、任务分配和版本控制。DevOps模式则需要有强大的自动化部署和持续集成工具。