软件工程实践总结——实践出真知

222200115吴俊斌 2024-12-20 23:39:27

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

一. 课程回顾与总结
1.回顾曾经思考过的问题
1.1 花费时间越多，代表工作量越高吗？
1.2 工作时是否应该带着个人、感情驱动的因素?
1.3 有了GPT类的应用，传统的搜索引擎是否会被完全替代？
1.4 AI辅助编程，是一个银弹么?
1.5 低层次的问题能依赖工具解决么?
2.产生了新的问题
3.项目中的阶段收获
3.1 需求分析阶段
3.2 设计阶段
3.3 实现阶段
3.4 测试阶段
3.5 发布阶段
4.个人项目经历
5.结对编程经历
6.团队项目经历
7.自我评分
二.个人技术总结
三.软件开发模式
3.1项目开发过程
3.1.1 项目概述
3.1.2 关键决策
3.2软件开发模式的思考
3.2.1 项目采用的软件开发模式
3.2.2 软件开发模式的效果
3.2.3 不同软件开发模式的对比
3.2.4 对软件开发模式的理解与思考

一. 课程回顾与总结

1.回顾曾经思考过的问题

软件工程实践的第一份博客
软件工程实践暑假作业
学习初期思考的一些问题:

1.1 花费时间越多，代表工作量越高吗？
- 在很早就已经明确的是，承担相同工作量的情况下，个人能力越高，花费的时间越少。之后需要研究的是个人承担某一工作量时，花费的时间与什么有关。在单人编写小型Demo时期，我认为是与寻找并纠正Bug有很大关系。在参与了相对综合的项目与团队项目后，我认为与选择合适的工具，搭建完善的框架有很大关系。在某一次项目中，我花费了三分之一的时间在寻找/搭建/调试框架上，甚至遭遇了与团队其他成员不兼容，而从头再来的逆境。这都是我之前未经历过的，花费极多时间，并且在我看来不属于常规工作量但又消耗许多精力的工作。
  1.2 工作时是否应该带着个人、感情驱动的因素?
- 和最早的想法一样，带着兴趣去工作，才能引导自己去思考并改进成果。基于结对与团队编程产生了一些新的理解，就是遇到自身进度的困难，或是遇到摆烂的合作者，这都会使自己产生焦虑或愤怒的情绪。纯负面的情绪我认为是需要调解并消灭的。这时理性是正常工作的基础。
  1.3 有了GPT类的应用，传统的搜索引擎是否会被完全替代？
- GPT在编码和消除Bug以外的任务上表现的很非人类。但是GPT无法解决的问题，传统搜索引擎同样难以解决。传统搜索引擎本质上也只是获取前人踩过坑后发现问题并发到网上的内容而已，依然存在很多时候问题无人解答的情形。
  1.4 AI辅助编程，是一个银弹么?
- 并非银弹。使用AI辅助编程，依然只能处理框架性的/重复性的任务，复杂度越高的任务，AI表现的通过率越低，启发价值也不高。想要取得编程上的突破，我认为需要掌握行业巨头的技术，以及对软件开发流程的深入理解。
  1.5 低层次的问题能依赖工具解决么?
- 早期的想法是还是需要自己手动处理，这样不会错，错了也有印象。现在认为刚需工具解决了，因为复杂度高的任务时间相当有限，在十余个文件，成千上万行的代码，甚至是别人写的代码里，去寻找低层次的问题，那太为难了，精力只能留给高层次的问题。

2.产生了新的问题

团队之间如何做好前后端分工？快速开发的过程中变量名存在歧义，如何避免？

3.项目中的阶段收获

3.1 需求分析阶段

需求规格说明
沟通技巧
需求分析对软件开发计划极其重要，这将直接影响软件功能模块的规划，类与数据库的构建，以及之后的一系列工作。即便采用了敏捷开发的模式，频繁的需求变动对工作人员的心理影响也是巨大的。因此，学习如何深入了解目标群体的核心需求，明白需求的来龙去脉，与项目的其他成员达成一致的认知，以及如何将需求转化为软件开发计划，是非常重要的。在有限的时间与资源下，筛选出功能需求，避免“竹篮打水一场空”。

3.2 设计阶段

架构设计
原型图
使用原型设计工具（如Axure，UML图）等可以清晰地向团队成员们展示项目的实际需求，减少实现阶段的沟通成本。通过制作流程图，可以将较为抽象的系统逻辑转换为直观的形式，帮助团队成员理解系统的架构。在设计阶段，需要注意模块之间的依赖关系，以及模块的接口设计。

3.3 实现阶段

前后端接口协调
版本控制
学习并掌握了以MVC为主的项目架构，做好了前后端的接口协调，并将构想与设计转化为实际的代码。在实现阶段，将课内学到的多领域的知识应用到实际项目中，同时积极上网寻找解决方案，起初看不懂，但对于项目有益的方法，都适宜学习并使用，但不宜盲目做增量，使用了自己都纠正不了的东西会在项目整合时被批斗。

3.4 测试阶段

单元测试
集成测试
了解了单元测试、集成测试的不同方法与工具，学习了从测试反馈中提取出需要改进的点，学会了通过黑盒测试与白盒测试来验证假设。

3.5 发布阶段

部署流程
用户反馈
我们的项目最终由组长在云服务器上进行部署。Web应用需要部署在Nginx+MySQL服务器上。该工作非我负责，但我知道服务器被关闭之后网页无法正常运行，需要维持服务器启动以正常发布。

4.个人项目经历

软件工程实践第二次作业——个人实战

学习新技术
这次实践涉及的技术繁多、陌生且杂乱，包括网站数据的爬取与解析，文件格式化与读写，数据的存储与处理，异常处理，单元测试，Git的使用等等，会遇到很多很多的感到一时无语，束手无策的困难。这次作业是我第一次深刻认识到工具与处理方法的重要性，也体会到如何在短时间内学会一项技术，并将其应用到实际项目中。

5.结对编程经历

结对第二次作业——编程实现

坎坷的初期
这次结对编程给我留下极为深刻的印象。首先是遇到了毫不配合的结对对象。起初的原型实现便是我一人完成。刚刚完成较为坎坷的个人作业后，这种情形让我感觉极为无助。好在之后加入了新的结对小组，重新获得了编码的动力。
灵活决策
相较于个人编程，结对编程的工作量较大，需要做好分工。由于时间技术有限，本次作业采用了纯前端的技术实现，数据通过js调用json文件来实现数据获取，具体代码只以采用了基本的三件套html、css、js。我们最初尝试创建服务器，但实践中频繁出现HTTP连接问题，在编码的过程中无暇解决。为此我们只能降低功能要求，使用async()获取数据，容易让用户感觉卡顿。但这也保证了我们交上了基本功能实现的成果。
与队友的沟通
与队友共同解决问题的过程增强了我们之间的沟通技巧。我认为在工作上遇到问题时，有能够交流的对象，是十分愉快的事。我们学会了如何有效地交流想法、分享进展，并共同克服困难。有效的团队协作不仅可以加速项目的完成，还能促进成员之间的成长和技术共享。

6.团队项目经历

轻氧七号——β阶段项目冲刺总结随笔

架构选择
团队前期由于沟通存在问题，导致项目架构未统一，导致成员想法出现偏差，在已经使用servlet和jsp完成模块开发后，团队决定采用基于springboot和html的项目架构，于是便紧急尝试进行转换。我花了三天的时间在编程架构的转换上。原因是我的idea是社区版而非企业版，无法直接使用spring initializer生成项目，只能转移到下载插件更为自由的VScode上进行配置。这使我了解到果然好用的工具是需要付费的。。。
前后端分离
在前两次编程工作都是纯前端的背景下，我终于开始了前后端的双端编写。这要求我掌握MVC（Model-View-Controller）的基本架构。Controller在处理请求，管理路由，视图解析上发挥很对我想要清晰的模块化的胃口。很讨厌变量名/文件名不规范，文件夹到处开的写法，给队友的可读性太低了。
安全性增强
因为项目的各个模块都有不同成员负责，但是需要解决用户认证与授权的问题，我们使用了Json Web Token（JWT）来实现用户认证。这样减少了会话状态的存储需求，这也使得我们的项目更加安全。
团队协作
还是需要做好良好的沟通。有时候自己一时卡壳的问题，问问队友说不定就有灵感了。作为组员，我及时将遇到的问题反馈给其他人，并得到了有效的建议。这让我与队友的工作对接良好。

总结

个人项目经历：个人项目经历让我对软件开发有了更深入的理解，也体会到如何在短时间内学会一项技术，并将其应用到实际项目中。
结对编程经历：结对编程让我对团队协作有了更深入的理解，也体会到如何有效地交流想法、分享进展，并共同克服困难。
团队项目经历：团队项目经历使我能够站在更高的层次上思考系统的架构设计，整理用户需求，实现更加精彩的设计。
未来肯定需要承担更多、更难的开发工作，我相信自己不会像这几次工作这么凌乱无措。希望我能够保持学习新技术与工具的兴趣，不因困难而产生太大的压力。

7.自我评分

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

评分：90
解释：软件工程师，无论多么高级，掌握并使用多么前卫与复杂的技术，都是工程师，也就是工人。工人就是要好好的打工，为用户而劳动，满足用户的一切需求，保障用户的一切权益。而作为网络上传播的一艘小舟，软件也需要承载起价值观的传播，为社会创造价值。利用用户数据牟利，随意中断服务等，显然是没有职业道德的行为，是在浪费用户对软件的信任与尊重。

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

评分：86
解释：面向对象设计课内已深刻学习了用况图/类图/流程图等的使用，并在项目的需求分析中应用。不过，面对复杂需求时，可能还需要花费较多的时间思考才能准确表达需求和设计。

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

评分：88
解释：在项目实践中，我作为组员参与了除发布外的软件开发全流程，从需求分析到体系结构设计再到软件的开发与测试。在项目实现前，我与其他成员沟通，敲定了前后端的模块化设计，并在答辩时由老师进行技术评审。根据老师提供的建议进行了设计优化。但由于人员变动，不同成员的理解不同，设计方案实现存在差异。

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

评分：83
解释：由于我并非组长，技术栈较浅，思路比较原始人，且技术测试只有上手并进行一段时间的运用才能有所认知，我认为技术评审能力需多加训练。

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

评分：86
解释：通过个人和团队项目的开发，我积累了文档撰写经验，能够遵循指定的标准格式，客观的进行文档编写。但对于个人比较有意见的内容，我会适当融入个人表述，应该无伤大雅。

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

评分：88
解释：在结对与团队项目中，我与成员们都进行了较多的沟通，因为不知道对方进度，看不懂对方代码就不安心。我尽可能保持项目能够向积极的一面发展，虽然也遇到不配合的情况，但我还是尽力协调。

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

评分：84
解释：在多次项目开发中，因为一开始未明确掌握可行的技术或工具，导致我根本无法预估什么时候能走回正轨。在技术条件准备就绪后，按需求划分工期，编写开发文档便是十分简单的事情。所以进度规划什么的还是得胸有成竹才能确定，最多预留一点时间给潜在的bug。

二.个人技术总结

个人技术总结——Spring Boot RESTful

三.软件开发模式

3.1项目开发过程

3.1.1 项目概述

项目目标：创建一个用户友好且功能丰富的个人健康管理系统，支持用户记录和管理日常健康数据（如体重等），提供个性化健康建议，同时实现运动记录和设备管理功能。
主要技术栈
- 后端：Java SpringBoot，MVC框架，实现轻松的依赖注入，更能专注与业务逻辑。
- /CSS/JavaScript，良好的静态资源管理。
- 数据库：关系型数据库MySQL，多表结构设计。
- 其他工具：Maven作为构建工具。

3.1.2 关键决策

技术选型：选择Java SpringBoot框架，因为它是轻量级的框架，能快速开发，同时也能实现依赖注入，自动配置，开发效率高。
资源分配：项目的资源与时间限制使我们专注于主要功能的开发。

3.2软件开发模式的思考

3.2.1 项目采用的软件开发模式

项目采用Scrum模式，Scrum是一种敏捷开发方法，它强调迭代开发，定期进行产品提交，即α冲刺与β冲刺，每日进行小组会议，汇报并整理当日成果。

3.2.2 软件开发模式的效果

1.敏捷开发模式的优点

快速迭代：定期完成一部分功能，并立即投入使用，实现项目完成进度可视化。
灵活性强：可根据需求变化迅速调整开发方向，避免浪费资源而无果。
团队沟通及时：每日站会实现信息共享，提高信息透明度，提高协作效率。

2.缺点

计划不完善：Scrum模式强调迭代开发，但准备时间短，原计划可能考虑不足，开发进度容易变动。
文档不完善：Scrum中成员会议中依赖口头沟通，在成员不足的情况下，文档开发需要消耗额外精力，常导致其不完善，关键信息未被记录。

3.2.3 不同软件开发模式的对比

瀑布模式 vs 敏捷开发：瀑布模式强调按顺序完成项目，处理变更小的项目，稳定性高。缺点是需求不明确时，瀑布模式开发效率低，风险大。团队开发项目由于时间限制大，需求存在变动，敏捷开发显然合适。
DevOps vs 敏捷开发：DevOps强调自动化，持续交付，持续部署，团队协作，敏捷开发强调迭代开发，快速反馈，快速响应。二者都追求高效的交付流程，但DevOps更注重持续交付与自动化运维，适合上线工期短但需要长期运营的企业级应用。

3.2.4 对软件开发模式的理解与思考

传统企业级软件开发模式：选择瀑布模式。对于需求稳定，规模较大的项目中，它有助于保质保量的管理进度。
互联网软件开发模式：选择敏捷开发模式。它能够快速响应市场需求，适合快速迭代的互联网产品开发。
大型服务级软件开发模式：选择DevOps模式。它能够实现自动化，持续交付，持续部署，团队协作，确保高频更新，服务稳定，适合大型软件项目的开发。
软件开发模式的选择：需要根据项目的大小、开发人员的数量、开发周期、需求变动频率、项目风险等因素，选择适合的软件开发模式。对于个人健康管理系统这样的6人开发，2周工期级别的小型项目，敏捷开发模式是最合适的。它最能够促进团队间沟通，便于及时修改。在未来的开发工作中，我将会参与更多开发模式的实践工作，体会不同模式的优缺点，并结合实际情况选择最适合的模式。

...全文