软件工程实践总结——在实践中成长

[222200429谢雨欣]

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

目录

• 第一部分：课程回顾与总结
• 一、重新思考
• 1.1 重新思考暑假作业的问题
• 1.2 重新回答这些问题
• 1.3 是否原来的问题还不明白
• 1.4 是否产生了新的问题
• 2. 知识收获
• 1.需求阶段
• 2.设计阶段
• 3.实现阶段
• 4.测试阶段
• 5.发布阶段
• 三、实践心得
• 1.个人项目
• 2.结对编程
• 3.团队项目
• 四、自我评价与课程目标掌握程度
• 4.1 职业道德与社会责任（98%）
• 4.2 需求分析（88%）
• 4.3 软件开发全过程（90%）
• 4.4 技术评测与创新设计（90%）
• 4.5 文档撰写（95%）
• 4.6 团队协作（100%）
• 4.7 项目管理（85%）
• 第二部分：个人技术总结
• 第三部分 : 软件开发模式
• 一、 项目开发过程
• 1.1 参与的项目
• 1.2 关键决策
• 1.3 遇到的挑战和解决方案
• 二、 软件开发模式的思考
• 2.1 采用的软件开发模式
• 三、 对比不同软件开发模式
• 四、对于软件开发模式选择的理解和建议

第一部分：课程回顾与总结

一、重新思考

1.1 重新思考暑假作业的问题

暑假作业博客

1.2 重新回答这些问题

1.在一个被认定为“足够好”的软件发布后，得到的用户反馈中，哪些是有用的？什么时候才能将这个软件优化到相对稳定的版本？

我认为一个“足够好”的软件不仅要在发布时满足基本的功能和需求，还需要在实际使用过程中根据用户反馈不断优化和改进。有用的用户反馈通常是关于功能性、用户体验、性能、错误修复及新需求的反馈，尤其是当这些反馈得到多个用户的验证时，说明它们是有效且具有普遍性的。
软件优化到相对稳定的版本通常意味着软件的核心功能已实现且稳定，性能良好，用户反馈集中在小的改进点和边缘情况。此时，软件应具有较高的可靠性和可维护性，能够满足大部分用户的需求，并且错误率较低。
总之，软件的“相对稳定”版本是一个动态的目标，需要不断根据实际使用中的反馈和需求进行优化，而不是一成不变的。

2.软件开发是年轻人的饭碗，吃的是青春饭？那年纪大的程序员经验丰富但是快速学习能力拼不过年轻程序员的时候该怎么办呢？

尽管年轻程序员在快速学习新技术方面可能具备一定的优势，但年纪较大的程序员可以通过发挥自己在技术深度和经验上的优势，找到适合自己的发展路径。大龄程序员通常具备扎实的计算机基础知识和丰富的项目经验，这使得他们能够快速掌握新工具和框架，理解其背后的原理，并在实际工作中做出高效的技术决策。即使面临技术更新迅速的挑战，持续学习和主动适应新技术也是非常重要的。除此之外，大龄程序员还可以选择转型为管理岗位或技术顾问，依靠自己的经验和团队协作能力发挥更大作用。无论是继续从事技术工作，还是转型管理岗位，保持积极心态、不断学习，并灵活应对变化，都能为大龄程序员提供更广阔的职业发展空间。因此，年龄并非限制，关键是如何利用经验、不断提升自己并适应不断变化的技术环境。

3.软件的行为和用户的期望值不一样，就一定是 Bug 吗？
软件的行为与用户的期望不一致并不一定代表存在Bug。可能是由于环境因素、设计与需求的差异、用户期望的多样性或功能实现的合理性问题等多种原因。开发人员应该通过详细的需求分析、测试环境验证、用户反馈和有效的沟通来判断问题的根本原因，并确保软件的功能设计与大多数用户的需求匹配。当软件的行为符合其设计目标和功能要求时，即使有部分用户的期望未被满足，也不应急于判断为Bug。

4.大陆高校中的计算机专业与软件专业是否并不像书中说的那样雷同？
计算机专业与软件工程专业在大陆高校中确实存在一定的区别，虽然它们在一些课程上有重叠，但整体方向和学习重点有所不同。
计算机专业通常是一个综合性更强的学科，既包括硬件也包括软件的内容。计算机专业的课程安排通常更加注重基础知识和广泛的技术领域，学生需要学习计算机硬件内容，同时还需要掌握一定的软件开发技能。计算机专业的学生可以根据个人兴趣选择从事硬件、网络、系统架构等方面的工作，因此其就业方向较为广泛。
软件工程专业则是一个更加专注于软件开发和工程化的学科。它的课程设计主要聚焦在软件开发的各个阶段，包括需求分析、设计、开发、测试、维护和项目管理等。软件工程专业更强调软件开发的流程、方法和实践，除了编程技能，还注重软件项目管理、团队协作、软件测试、系统架构设计等方面的能力。软件工程专业的学生更倾向于从事软件开发、系统分析、项目管理等工作。
此外，计算机专业和软件工程专业的学科深度和技术广度也有所不同。由于计算机专业要同时涵盖硬件和软件，可能在每个领域的深度上稍显薄弱，而软件工程专业在软件开发方面的深度会更强，能够更好地适应当前企业对软件开发工程师的需求。

5.花费时间越多，代表工作量越高吗？
虽然通常情况下花费的时间和工作量是相关的，但时间的长短并不完全等同于工作量的大小。程序员的能力、技术栈、工作习惯、任务的复杂性以及外部因素都可能影响工作完成的时间。因此，评估工作量时，应该综合考虑各方面的因素，而不仅仅依赖于时间的长短。

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

没有了

1.4 是否产生了新的问题

• 在解决技术难题时，如何有意识地进行知识总结，形成可复用的技术方案，减少以后重复解决相同问题的时间和成本？
• 如何处理团队成员在技术方案、代码风格、开发进度等方面的不同意见，保证团队的高效合作与共识形成？

2. 知识收获

1.需求阶段

在需求阶段，最重要的是从用户的角度出发，深入挖掘真正的需求，而不仅仅是解决表面的问题。通过学习需求工程的关键方法，例如需求获取、需求建模和需求分析，我深刻理解到需求文档的清晰性和准确性对项目后续阶段的重要性。学会了使用结构化的方式来收集、分析和记录用户需求，尤其是通过工具如UML用例图，将模糊的用户需求转化为明确的功能需求。此外，我也意识到需求变更是不可避免的，并学会了如何通过版本化需求文档来有效管理这些变更。在ETennis项目中，我们通过用户调研和问卷收集，发现用户不仅需要功能实用的迎新系统，还特别在意页面的直观性和简洁性。这一发现让我更深刻地理解了需求分析的核心——站在用户角度思考问题，才能真正解决他们的痛点。

2.设计阶段

在设计阶段，需要详细了解项目的需求和目标。在理解需求的情况下进行原型设计，前端的设计中需要考虑如何通过颜色、字体、间距等设计元素突出重点，注意视觉层次。规范设计，掌握了设计系统和组件库的使用，理解一致性设计的重要性，确保网站整体风格统一。在设计交互界面时，需要平衡视觉美感与功能需求，学习如何使界面既美观又实用，如何简化用户操作流程，提高界面的响应速度和可用性。

3.实现阶段

深入理解代码规范和重构的重要性，学习编写简洁、可读、可维护代码的方法。了解如何使用版本控制工具进行多人协作开发。提高了程序实现的技能，包括前端页面实现和接口调用等实践能力。学习了通过API文档与后端团队协作，明确数据接口的返回格式以及必要的数据字段。培养了调试和解决实际问题的能力，能够快速定位和修复代码中的问题。学会通过持续集成工具实现自动化构建和简单测试。

4.测试阶段

掌握设计测试用例的基本方法以及测试工具。在测试过程中提升了发现、分析和修复缺陷的能力。能够根据测试结果不断调试、改善代码和功能实现。学会根据系统的关键功能和用户行为优先级分配测试资源，最大化测试覆盖率。

5.发布阶段

优化小程序展示效果并修复一些隐藏的bug。了解实际开发和uniapp转小程序中语法冲突的问题，并撰写了用户体验调查报告，收集用户反馈，有利于更好地发现项目问题并进行改善和提升，有助于新版本的发布。在此期间，培养了协作沟通和流程优化的能力，为日后参与复杂的发布任务奠定基础。

三、实践心得

1.个人项目

通过软件工程实践作业，我深刻体会到软件工程远不只是简单的代码编写。在个人项目中，我深入实践了数据爬取、存储与查询的技术，尤其是在爬取复杂格式的数据时，通过使用 requests 和异常处理，解决了数据格式不一致的问题。在项目开发过程中，我注重接口的设计和代码的模块化，使得系统更加清晰、易于维护。我还学习了如何通过缓存和数据结构优化查询性能，大大提高了程序的效率。此外，通过实现单元测试，我提高了代码的稳定性和可扩展性。整体而言，这些个人项目加深了我对数据处理和系统设计的理解，锻炼了我的问题解决能力和技术实践经验。通过这些个人项目，我也意识到在时间管理和代码规范方面仍有提升空间，未来会更加注重细节和效率。

2.结对编程

我的项目经验较少，且给的时间并不多。实现奥运会网站对我而言是一个全新的挑战， 在了解项目要求后，学习使用墨刀进行原型设计，在此过程中实现项目雏形并不断根据使用状况进行页面的改善。项目实践时，有许多需要学习和了解的知识，学习Git的具体操作，学习前端接口的实现，前后端的交互等。在实践中不断巩固自己的知识，促进项目的完成。在结对合作中我也了解到团队交流的重要性，需要不断沟通和理解促进项目的实现。我之前写过项目的前端，但接口的部分我还不熟悉，我请教了团队中前端的负责人和我的搭档。在完成项目的过程中我们也遇到了很多问题，我们一点点的修改，完善。

3.团队项目

在这次项目中，我收获了很多宝贵的经验，尤其是在前端开发方面。首先，我深刻认识到了自己在样式排版上的不足。尽管平时会注重UI设计和视觉效果，但在实际开发中，排版的细节和一致性却常常容易忽视。通过与队友的协作和项目中的实际应用，我学会了更加细致地处理样式问题，确保每个元素的布局和配色都能呈现出最佳效果。这不仅提升了我的排版能力，也让我对UI设计有了更深的理解。
另外，这次团队项目也让我意识到接口逻辑处理的重要性。最初在处理接口请求时，我常常忽略后端提供的接口文档和示例，但在实际开发中，我逐渐学会了使用apifox来尝试与后端对接，学会从前端的角度去理解和处理接口的调用和错误处理。
此外，pinia的尝试也是这次冲刺中的一大收获。pinia它更加简洁和灵活。通过封装pinia，我不仅能更好地管理和共享应用状态，还能提升代码的可维护性和扩展性。学习和使用pinia让我对状态管理有了更深的认识。
总的来说，软件工程实践不仅让我提升了前端技能，还让我更好地认识了自己在开发中的不足和成长空间。未来我会继续加强对前端技术的学习，尤其是排版、接口处理和状态管理等方面，不断提升自己的技术能力。

四、自我评价与课程目标掌握程度

4.1 职业道德与社会责任（98%）

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

关于软件工程师的职业道德规范和实践要求，在项目开始前其实就有一定的了解。并且作为一名社会主义青年和发展对象，对于社会现状有一定的了解，但是由于部分专业知识的欠缺可能没法考虑的十分全面。通过课堂学习和项目实践，我深刻认识到软件工程师的职业道德规范，如开发高质量、可持续的产品，以及保护用户隐私的重要性。

4.2 需求分析（88%）

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

在课堂和项目中，在这几次项目过程中我多次使用NABCD模型帮助项目的需求分析，同时也参与了er图的绘制。但面对小众、复杂业务场景，还要多积累案例，打磨技巧。我能使用需求表达工具准确描述需求，并通过构建需求模型规范化需求表达。然而，在处理复杂需求变更和冲突时，我的经验仍需积累。

4.3 软件开发全过程（90%）

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

通过这门课程，我对软件开发的全过程有了更为系统的理解。在"巴黎奥运会网站"和"ETennis"的开发中，我分别负责前端开发和小程序前端开发，我参与了整个开发过程的协作。通过敏捷开发和不断的迭代，我们逐步完善了产品的功能和用户体验。在开发过程中，我不仅关注功能实现，更重视与后端开发者的紧密配合，确保数据传输和接口调用的高效性。这一过程中，我深入了解了软件开发中的调试、优化等重要环节，我能够把控小程序页面设计从原型到实现的过程。并且能够实现功能模块化，考量模块的独立性与关联性，但在整体架构设计和系统性能优化方面，我的经验还比较薄弱，未来需要通过更多实践来提升。

4.4 技术评测与创新设计（90%）

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

我能够对组件和系统进行功能测试，并结合团队评审，优化设计方案。在技术评测和创新设计方面，我已经能够较为成熟地进行技术方案的评估，并提出优化建议。例如，在"巴黎奥运会网站"和"ETennis"项目中，我参与了网站的前端设计和技术评审，针对交互设计和响应速度等方面提出了多个创新改进方案，提升了用户体验。未来我将更多地参与技术前沿的研究，并多多尝试新的技术和设计模式。

4.5 文档撰写（95%）

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

我能够按照标准撰写项目文档，包括需求规格说明书、系统设计说明书和测试报告。文档撰写是我在团队中参与的重要一环。通过课程学习，我掌握了如何清晰、规范地撰写文档，并能够用专业的语言表达复杂的技术内容。我在文档的结构和内容上都力求简洁明了，确保团队成员能够快速理解。然而，在面对更复杂项目时，如何在文档中更好地梳理架构设计、系统性能等方面的内容，还需要进一步提升。例如，在需求文档中，有时面对变化频繁的需求，我们如何高效记录并及时调整文档内容，仍是我需要加强的技能。

4.6 团队协作（100%）

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

在团队项目中，我积极与成员沟通，分工明确，并通过有效的工具协作完成任务。我还尝试协调团队解决冲突，提升整体效率。团队协作是我在课程中学到并在项目中应用最多的内容之一。我与团队成员密切配合，及时共享信息，积极沟通，不仅确保了任务分配的合理性，还增强了整个团队的凝聚力。团队协作让我更加理解了协同工作的重要性，在团队中的沟通能力和协调能力得到了显著提升。

4.7 项目管理（85%）

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

我能够使用项目管理工具规划项目进度，并对任务优先级进行合理安排。项目管理是我在这门课程中掌握的一项核心技能。在“ETennis”项目中，我参与了项目的任务分配和进度跟踪，确保各个环节按时完成。但在项目管理过程中，如何应对突发情况、如何优化资源配置、如何合理安排工作量等方面，我的经验还不足。在实际的项目中，我能够掌握基本的工作量估算和进度管理，但在复杂的大型项目管理中，如何应对更复杂的挑战，需要我进一步提升自己的项目管理能力。

第二部分：个人技术总结

• 个人技术博客：Axios的使用总结
• 概述：Axios 常用于前端项目中与后端 API 进行数据交互。在团队开发网站项目中，为了解决跨域问题并规范错误管理，我们选择使用 Axios 作为数据请求工具。本技术博客将介绍如何配置 Axios 实例，Axios 的常用请求方法，API 封装，统一错误处理以及相关技术的难点和解决方案。

第三部分 : 软件开发模式

一、 项目开发过程

1.1 参与的项目

ETennis网球俱乐部管理系统是一个基于“Uni-app + Vue3 + SpringBoot”技术栈开发的综合平台，旨在为网球俱乐部提供高效的赛事、战绩和选手管理功能。系统包括面向会员的微信小程序和面向俱乐部管理者的网页端，核心功能包括赛事管理、战绩管理和选手管理。通过系统，俱乐部可以创建和管理各类赛事，记录和展示选手的历史战绩，管理选手个人信息并提供最佳对手匹配。同时，管理者可以通过后台进行决策、管理数据并提升运营效率。会员通过微信小程序方便地查询赛事信息、报名参赛、查看个人战绩，从而优化用户体验。整体而言，ETennis系统旨在提升俱乐部管理效率、优化选手体验、提高服务质量。

1.2 关键决策

• 前端技术选型：微信开发工具转为uniapp。参与前端开发的成员具备扎实的Vue基础，且Uni-app支持直接发布为微信小程序，为了节省学习新技术的时间，最后决定改用与Vue关联性较强的Uni-app来开发小程序。虽然这一决策加快了开发进度，但在将项目转化为微信小程序时，我们也遇到了一些预期中的技术难题。这些问题主要集中在兼容性和性能优化方面，但由于我们在项目初期已经预料到可能出现的挑战，并为此安排了充足的时间进行调试和优化，因此能够及时有效地解决这些问题，确保了开发进度不受过大影响。

• 版本控制：我们采用了 Git 作为版本控制工具，以确保项目开发过程中代码的高效管理和稳定性。Git 让开发团队能够在多个开发分支上并行工作，减少了代码冲突的发生，提升了团队协作的效率。通过定期提交代码和拉取最新的代码版本，团队成员能够及时获取到彼此的修改，避免了开发进度的滞后和重复劳动。

1.3 遇到的挑战和解决方案

• 挑战 : uniapp开发时在浏览器上展示的效果与在真机/微信开发者上面不同，很多方法和样式需要重新修改。
• 解决办法 : 跟据uniapp官方文档和微信开发者文档来调整语法，保证能在真机上正常运行与显示。

二、 软件开发模式的思考

2.1 采用的软件开发模式

Scrum+Spiral : 本项目采用了Scrum和Spiral两种开发方法的结合。首先，在Alpha阶段，团队通过两个Sprint周期进行核心功能的开发，并在技术评审中收集反馈。根据这些反馈，在Beta阶段对产品进行了进一步优化，包括修复已知问题、增强功能、改善用户界面、提升用户体验以及进行性能优化。

此外，项目还借鉴了Spiral模型的部分理念，特别是在风险管理方面。在每个迭代周期前，团队对项目的技术、进度、成本和人员等方面的风险进行了分析和评估，并在识别到潜在风险时，及时采取措施进行应对，从而确保项目的顺利推进和按时交付。

• 优点: Scrum+Spiral结合了Scrum的敏捷迭代特性和Spiral模型的风险管理机制。Scrum提供了灵活的迭代周期，允许快速反馈和持续改进，而Spiral则通过早期和频繁的风险评估和管理，帮助团队在开发过程中识别并应对潜在问题。
• 缺点: Scrum+Spiral的结合可能会带来一定的复杂性。Scrum强调快速迭代和小步快跑，但Spiral模型则要求频繁的风险评估和阶段性审查，这可能会增加项目的管理负担。
• 对开发效率的影响： Scrum+Spiral模型的结合有可能提高开发效率，但这取决于团队如何平衡敏捷性和风险管理。Scrum的短周期迭代可以确保产品持续改进和增量交付，而Spiral则通过有效的风险管理避免了不必要的返工和资源浪费。如果能有效整合两者的优点，项目可能会更加稳定，减少中途大规模的调整，从而在长期内提高开发效率。
• 对团队协作的影响： Scrum+Spiral的结合对团队协作有积极影响，因为它鼓励频繁的沟通和反思。在Scrum中，团队成员每个Sprint都进行回顾和计划，确保协作高效。
• 对最终交付的影响： Scrum+Spiral模型的结合有可能提高最终交付质量和准确性。Scrum的迭代和反馈机制可以确保产品在整个开发过程中得到持续优化，而Spiral模型的风险评估帮助项目在每个阶段进行充分的验证和调整，避免了最终交付时的重大问题。

三、 对比不同软件开发模式

开发模型	优点	缺点	适用场景
瀑布模型	结构简单，文档全面，易于管理，适合需求明确且变化较少的项目	灵活性差，需求变更难以应对，开发过程中较难进行调整和改动	需求明确且变化较少的小型项目，尤其是政府和金融类项目
增量模型	早期交付、灵活性高、风险管理得当，可以在每个增量中获取反馈	可能会出现重复开发工作，集成复杂度高，初期可能不完整	大型系统开发，需求不稳定、逐步演化的项目
螺旋模型	高度灵活，结合风险评估和迭代开发，逐步完善需求和设计	成本较高，管理复杂，需要大量资源进行持续评估和验证	高风险项目、需求经常变动并需要逐步完善的项目
敏捷开发	快速反馈、迭代开发、团队协作强，适应变化快，客户参与高	可能缺乏全局规划，难以进行大规模管理，部分团队可能缺乏经验	小型团队，需求频繁变化或优先级不确定的项目
迭代模型	灵活性高，客户持续参与，逐步完善功能，逐步交付价值	可能缺乏整体规划，部分功能可能未充分测试或集成	中大型项目，逐步实现功能并不断改进的项目
组件开发	高度重用，模块化开发，易于扩展和维护，缩短开发周期	组件集成复杂，可能对现有组件的依赖影响创新和灵活性	高度模块化和可扩展性强的项目，特别是产品化平台开发
DevOps	高效的协作与沟通，持续集成和持续交付，自动化部署，快速反馈和恢复	初期实施复杂，要求团队有较高的技术能力，需要组织文化的转型	大型、复杂的系统开发，高可用性、高频发布的项目，特别是云计算、微服务架构项目

四、对于软件开发模式选择的理解和建议

• 理解 :
  在选择合适的软件开发模式时，需要考虑项目的需求稳定性、复杂度、团队能力和交付周期等多方面因素。每种开发模式都有其独特的优势与局限性。例如，瀑布模型适合需求明确且变化少的项目，增量模型和迭代模型适合需求逐步明确或变化较大的项目，敏捷开发则适用于需求频繁变化、开发周期短的项目。选择合适的开发模式能够帮助团队高效地应对项目的挑战、降低风险并确保按时交付。
• 建议 :
  在选择开发模式时，建议根据项目的规模、复杂度和风险进行综合评估。如果项目需求清晰且稳定，可以考虑使用瀑布模型或增量模型；若需求不确定或容易变动，敏捷开发或螺旋模型将更有优势。对于大型系统或复杂架构，增量模型和DevOps能够更好地支持快速迭代与持续交付。最重要的是，团队应根据自身技术水平和管理经验来选择开发模式，以确保流程顺畅并有效管理项目进度和质量。