软件工程实践总结——回望与前行

222200413陈志鸿 2024-12-20 22:01:15

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

一、课程回顾与总结
1.以前问题思考的博客链接
2.对问题再次进行解答
3.每个阶段的收获
3.1需求阶段
3.2设计阶段
3.3实现阶段
3.4测试阶段
3.5发布阶段
4.实践心得
4.1个人项目
4.2结对编程
4.3团队项目
5.自我评估
二、个人技术总结
三、软件开发模式
3.1项目开发过程
3.2软件开发模式的思考
3.2.1选择的开发模式：Scrum + Spiral
3.2.2开发模式的优缺点分析
3.2.3开发模式对项目的影响
3.2.4不同软件开发模式的对比与适用场景
3.2.5对于软件开发模式选择的理解和建议

一、课程回顾与总结

1.以前问题思考的博客链接

软件工程实践暑假作业-CSDN社区

2.对问题再次进行解答

如何预估任务的时间：

在经过了结对作业和团队作业后，我进一步认识到预估任务时间是一个复杂的过程，需要考虑多个因素。在设计PSP表格时考虑了以下因素：首先，对任务进行详细分解，识别出各个子任务和它们之间的依赖关系。其次，评估每个子任务的难度和所需的技能水平，结合团队成员的经验和能力来估计完成每个子任务所需的时间。此外，考虑潜在的风险和不确定性，为这些不可预见的因素预留缓冲时间。最后，通过迭代和反馈调整预估，以提高准确性。
花费时间越多，代表工作量越高吗：

我的回答仍然是花费时间多不一定代表工作量高。花费时间的长短并不总是与工作量成正比。在团队作业和结对作业中，我负责的都是前端开发，有时会因为一些较为复杂的问题反复修改代码对样式进行调整，但是工作量实际上并不算大。我也意识到，任务可能因为复杂性高、难度大而需要更多时间，但这并不意味着工作量就一定大。同样，工作效率低下或频繁中断也可能导致花费时间增加。
变量命名是否应该有描述：

这个问题我也同样保持原本的观点：变量命名应具有描述性。一个好的变量名应该能够清晰地传达变量的用途和含义，同时避免不必要的复杂性。这有助于提高代码的可读性和可维护性。这个在团队作业中和其他成员合作开发的时候深有体会，好的变量命名能让队友能够快速清晰的理解变量的用途和含义，提高开发效率。
我都是大学生了，上课还要认真听老师讲课么：

我认为作为大学生，认真听讲仍然是非常重要的。尽管大学生已经具备了一定的自学能力，但认真听老师讲课仍然是大学教育中不可或缺的一部分。因为在学习过程中，在理解一些问题时，有时候需要花费很多时间。而在课堂上，老师能给同学讲解重要知识点，有助于我们全面理解和掌握课程内容。因此，尽管具备一定的自学能力，课堂学习仍然重要，它是获取全面知识和提升综合能力的重要途径。
团队成员的学习能力不一，要如何平衡：

在这次团队作业中，我担任了前端开发小组长，对于在团队中平衡不同学习能力的成员，首先，我先了解了成员所掌握的技术，根据各自的能力分配任务，确保每个人都能在自己擅长的领域发挥作用。其次，鼓励团队成员之间的知识共享和协作，以帮助学习能力较弱的成员提升技能。此外，beta阶段项目经理给我们安排任务时，给我们设置了任务完成ddl，我也意识到，设置ddl可以促进成员的学习，提高团队的开发效率，为团队创造一个支持性和鼓励性的学习环境，鼓励成员相互学习和成长。

3.每个阶段的收获

3.1需求阶段

在需求阶段，我学会了如何深入挖掘用户的真实需求，而不仅仅是解决表面的问题。通过运用NABCD模型，从需求、优势、竞争和推广等多个维度评估项目的可行性和价值，将模糊的用户需求转化为明确的功能需求。此外，我也意识到需求变更是不可避免的，并学会了如何通过版本化需求文档来有效管理这些变更。在ETennis项目中，通过收集到的用户需求进行分析，我们团队站在用户角度思考问题，理解他们真正的需求，解决他们的痛点。通过这个过程，我学会了如何将用户的语言转化为开发团队可以理解和实现的需求，这对于确保项目成功至关重要。

3.2设计阶段

在设计阶段，了解并学习使用了Figma、apifox、UML图等工具。

学习使用Figma进行原型设计，不仅让我掌握了创建美观且用户友好的界面原型的技能，还让我深刻理解了用户体验设计的重要性。在团队作业和结对作业原型设计过程中，我和队友交流设计思路，从不同视角发现设计的亮点和不足，从而提升设计的全面性和创新性，同时确定主题色、辅助色和字体等样式逐步完成项目的原型设计。

使用apifox进行接口设计，我学会了如何高效地设计和测试API接口。在团队作业和结对作业中，我和后端通过apifox，定义了接口文档规范，指定请求方式（如GET、POST、PUT等），设置请求参数等。通过这个过程，我学会了定义清晰的接口规范，同时也为后续的接口调试和自动化测试打下了坚实的基础。

3.3实现阶段

在实现阶段，我深入理解了代码规范和重构的重要性。同时，我也了解了如何使用版本控制工具，如Git，来进行多人协作开发，这包括分支管理、代码提交、合并以及冲突解决等技能，这些工具和技能对于团队协作和代码管理非常重要。在技术实践方面，我提高了程序实现的技能，特别是在前端页面的构建和后端接口的调用上，同时，通过在ETennis小程序开发过程中封装了后端请求的接口，我还学会了封装部分通用接口，并将设计阶段的原型转化为实际的代码，确保它们能够正确地与后端服务进行交互。

3.4测试阶段

学会了编写单元测试和关注代码覆盖率，了解了多种测试方法，包括功能测试、性能测试、压力测试和用户体验测试。我学会了从测试反馈中提炼关键问题，并运用数据和定性分析相结合的方法来验证问题和改进方案的有效性。这帮助我更准确地定位问题，并确保解决方案能够满足用户的实际需求。这使我能够从逻辑层面发现并修复潜在的问题，确保代码的健壮性。我明白了测试人员与开发人员紧密合作的重要性，及时反馈问题并修复，以提高项目的稳定性和可靠性。

3.5发布阶段

在团队项目中，我熟悉了微信小程序的发布过程和规范及其审核机制，修改项目代码，确保项目符合平台要求、具有良好的性能和兼容性。在这个过程中，我锻炼了解决技术问题和应对审核反馈的能力。

4.实践心得

4.1个人项目

经过个人项目开发，让我对项目管理有了更深刻的理解。通过使用PSP表格，我学会了对任务的时间估计与实际记录，通过明确任务细分，更好地掌控了开发进度，这对我的时间管理能力是一次极大的提升。在项目中，我不仅锻炼了我的编程技能，特别是在数据处理和JSON解析方面，还学会了如何编写单元测试来确保代码质量。

4.2结对编程

结对编程的经历教会了我团队合作的重要性。在与搭档一起工作的过程中，我学会了如何更有效地沟通和协作，共同解决编程难题。我们在原型设计和编程实现上的合作，不仅提升了我的技术能力，也锻炼了我的沟通和协调技巧。我也意识到，通过发挥彼此的长处可以更高效地完成任务，实现1+1>2。

4.3团队项目

在团队项目中，我使用Uniapp开发小程序，这让我对前端开发有了更深的认识。我发现自己在CSS样式优化和布局设计上还有很大的提升空间。通过不断的实践和调整，我更加熟悉了CSS的用法，并积累了保持页面风格统一的经验。同时，我也深刻体会到了接口对接的重要性。在初期遇到接口返回数据格式不一致等问题时，我通过查阅文档、搜索资料和与后端沟通，逐步掌握了高效调用和调试接口的方法，也提高了我的沟通交流能力。

5.自我评估

课程目标	掌握程度	解释
理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。	88%	在参与项目开发中，我深入了解了软件工程的社会影响，尤其是在为网球俱乐部开发量身定制的小程序时，考虑到了俱乐部的需求和选手的体验，注重产品对用户的实际价值和社会贡献。
掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。	90%	在需求文档的制定过程中，我准确地提炼了客户的需求，并根据实际情况进行了详细分析。通过需求表达工具，明确了功能模块和需求细节，确保了需求的准确传达。
掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。	85%	我在系统设计说明书的制作中，参与了从架构设计到组件设计的全过程。尽管完成了设计方案的编写，但在一些复杂模块的设计中，仍需进一步提升架构优化的能力。
能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。	86%	在开发过程中，我参与了功能模块的设计和评审，能够对设计方案进行基本评判，并提出改进意见。但在创新设计方案的选择和优化方面，经验仍需积累。
遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。	89%	在项目中，我编写了详尽的需求文档、系统设计说明书，并与团队进行讨论和修改，确保了文档的规范性。通过这些文档，与团队进行了有效的交流和协作。
具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。	93%	在与队友共同开发小程序时，我担任主要负责人，确保了团队之间的有效沟通与协作。通过明确任务分配和定期沟通，保证了项目的顺利进行，并促进了团队的协作氛围。
能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。	83%	在项目管理过程中，我负责了部分进度规划和任务分配，掌握了项目管理的基本工具和方法，但在大规模项目管理和复杂问题的应对上，还有进一步提升的空间。

二、个人技术总结

个人技术博客——uni.request的使用总结-CSDN社区

概述：uni.request 是 UniApp 提供的网络请求 API，用于发送 HTTP 请求。它支持 GET、POST 等多种请求方式，能够处理常见的网络操作，如请求头、参数传递、响应处理等，适用于与后端进行数据交互。通过 uni.request，开发者可以方便地实现接口调用、数据获取和错误处理。

三、软件开发模式

3.1项目开发过程

参与的项目
ETennis网球俱乐部管理系统
该项目旨在为网球俱乐部提供一体化的管理解决方案，包括会员管理、赛事管理和选手战绩管理等。通过微信小程序和网页端，提升俱乐部的运营效率和服务质量，同时优化选手的使用体验。
项目目标
- 为网球俱乐部成员提供便捷的赛事报名、比分上传和战绩查询功能。
- 为俱乐部负责人提供完整的选手管理、战绩管理和赛事管理工具。
- 提升管理效率，减少人工操作，提高业务流程的自动化水平。
- 提供实时的数据分析和可视化展示，帮助俱乐部更好地管理赛事并评估选手表现。
主要技术栈

Uni-app + Vue3 + SpringBoot
关键决策
- 前端技术选型： 初期计划使用微信开发工具进行小程序开发，后面考虑到团队成员已经具备较好的Vue3基础，且Uni-app能够发布为微信小程序，最终选择了Uni-app进行开发。
- 开发计划调整： 在Alpha阶段，考虑到开发时间紧张且部分业务逻辑较为复杂，我们团队对开发策略进行了调整：简化复杂业务逻辑，降低开发难度；推迟部分非核心功能的开发；减少某些次要功能的实现要求，确保核心功能能够顺利交付。
- 版本控制：使用 Git 进行版本控制，保证了开发效率和代码的稳定性。
遇到的挑战和解决方案
- 挑战：
  1. 小程序发布问题：在Uni-app转换为微信小程序的过程中，遇到了几个兼容性问题，包括部分样式不生效、部分图片无法显示等。
  2. 小程序体积限制：微信小程序的主包大小限制为2MB，而实际项目的体积超过了5MB，这导致了上传和发布的小程序无法通过审核。
- 解决方案：
  1. 针对语法兼容问题，我们根据Uni-app和微信开发文档进行了样式调整，确保小程序的兼容性。
  2. 针对小程序体积超标问题，将部分静态资源托管到云端，通过网络请求动态加载，以减小主包体积，确保符合微信小程序的大小限制。

3.2软件开发模式的思考

3.2.1选择的开发模式：Scrum + Spiral

在ETennis网球俱乐部管理系统项目中，我们选择了Scrum和Spiral的组合开发模式。Scrum的迭代性和灵活性非常适合我们的项目，因为该项目需求不断变化，需要频繁的用户反馈和调整。通过每个Sprint的短期目标，我们能够快速迭代并根据反馈进行调整，确保开发方向与用户需求一致。同时，结合Spiral模型的风险管理特性，使得我们在面对技术难题和需求不明确时能够进行有效的风险评估与控制。每个迭代周期的规划和设计阶段都有助于提前识别潜在问题，确保项目能够应对技术挑战并减少开发中的不确定性。这种开发模式的结合使得我们在需求变化和技术复杂性较高的情况下，既能保持开发的灵活性，又能有效管理风险，最终保证了项目按时高质量地交付。

3.2.2开发模式的优缺点分析

优点：
- 适应性强： Scrum和Spiral都能灵活应对需求变化和不确定性。在项目的过程中，客户需求会随着时间变化，而这种开发模式的灵活性确保我们可以及时调整开发方向。
- 高效的团队协作： Scrum强调团队成员之间的紧密合作，定期的会议和反馈环节加强了沟通与协作，提升了团队的整体效率。
- 风险控制： Spiral模型的引入有效地控制了项目中的技术和需求风险。在每个周期内进行风险评估和管理，减少了后期出现重大问题的概率。
- 快速交付与反馈： 每次迭代交付一个可用版本并进行评审，能够迅速获得客户反馈，帮助我们在开发过程中做出调整，确保最终交付的产品符合客户需求。
缺点：
- 项目管理复杂： Scrum和Spiral的结合增加了项目管理的复杂性。Scrum要求严格的团队协作和频繁的进展评估，而Spiral则要求在每个阶段进行详细的风险分析和管理。对于一些团队成员来说，这种双重压力可能会增加管理负担。
- 需求变化的影响： 尽管Scrum具有很好的适应性，但频繁的需求变化仍可能导致开发方向的不稳定，增加了开发成本和时间。
- 文档和记录： 由于Scrum强调快速交付和功能迭代，可能会出现文档记录不完整或更新不及时的问题，影响长期维护和后续开发。

3.2.3开发模式对项目的影响

开发效率：
Scrum的迭代性确保了项目可以快速推进，尤其是在我们面临复杂功能需求时（如赛事管理和选手战绩分析）。通过每个Sprint交付可用版本，我们能有效验证功能的实现，减少大规模重构的风险。Spiral模型则通过阶段性的评估与规划，避免了盲目开发，确保了开发过程的高效性。
团队协作：
Scrum框架下，我们团队成员间的日常沟通和协作大大加强了团队的凝聚力。在每个Sprint开始时，团队就明确了目标，分工清晰，大家齐心协力推进项目。定期的Sprint评审和回顾会议让团队能实时调整工作方向，有效避免了沟通障碍和任务滞后。

3.2.4不同软件开发模式的对比与适用场景

开发模式	适用场景	优点	缺点
瀑布模型	需求明确、变更较少的项目	1. 流程简单，易于管理 2. 适合需求完全清晰的项目 3. 每个阶段都有明确的交付成果	1. 不适应需求变化 2. 难以提前识别和解决问题 - 后期修改成本高
敏捷开发	需求不完全明确或频繁变化的项目	1. 快速响应需求变化 2. 高度灵活，能够根据反馈调整 3. 强调团队协作与沟通	1. 可能导致需求不明确 2. 对团队自我管理能力要求高 - 进度不易预测
Scrum	需要高频迭代、频繁交付反馈的项目	1. 快速迭代，确保持续交付 2. 强调客户反馈，适应需求变化 3. 高度协作与沟通	1. 需要团队高度自律 2. 频繁的评审会议可能增加管理成本 3. 短期目标易导致短视
Spiral	高风险、需求不完全明确、技术挑战大的项目	1. 强调风险评估与管理 2. 灵活适应复杂需求 3. 每次迭代包含规划、设计、开发、测试等多阶段	1. 高开发成本与时间 2. 需要持续的风险管理
DevOps	需要频繁发布和更新的项目	1. 快速交付，自动化部署 2. 改善开发与运维协作 3. 提升产品质量和稳定性	1. 需要高度的技术投资和基础设施支持 2. 对团队要求高

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

通过实际项目开发经验，我认为，选择开发模式应依据项目的特点、团队的技能、以及客户的需求。

对于复杂且需求可能不断变化的项目，对于ETennis这样的小程序开发，Scrum与Spiral的结合是一个非常适合的选择。Scrum帮助我们进行快速迭代，而Spiral则为我们提供了风险管理的框架。在面对需求变化较多、技术复杂度较高的情况下，结合敏捷和螺旋模型，既能保证开发的灵活性，又能减少因技术问题带来的风险。对于其他项目，如果需求相对稳定且开发周期较长，使用瀑布模型可能会更加高效。而对于需要快速上线、频繁更新的项目（如一些在线服务），建议采用DevOps模式以提升发布效率。

总之，我认为软件开发模式的选择并没有绝对的标准，关键在于根据项目的实际情况灵活调整和应用，才能在保证质量的前提下，提高开发效率和团队协作的能力。

...全文