软件工程实践总结——深耕细作

222200104邓彦茜 2024-12-20 22:26:02

这个作业属于哪个课程	2024软件工程实践W班
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	课程结束后进行回顾和总结，然后完成个人技术博客
其他参考文献	《构建之法》

一、课程回顾与总结
1.1 第一次博客的链接
1.2 回顾之前的问题
1.3 五个阶段中学习到了什么
1.4 项目的理解和心得
1.5 自我评分对七大课程目标的掌握程度
二、个人技术总结
三、软件开发模式
3.1 关于我参与的项目
3.2 对软件开发模式的思考
3.2.1 项目采用敏捷开发 Scrum框架
3.2.2 不同开发模式的对比与适用场景
3.2.3 对软件开发模式选择的思考

一、课程回顾与总结

1.1 第一次博客的链接

软件工程实践暑假作业
1.2 回顾之前的问题

问题1：我都是大学生了，上课还要认真听老师讲课么？
再次回答：在软件工程实践中，我更深刻地认识到老师课堂上的经验分享是无可替代的。老师讲解的知识点往往是经过多年行业实践的总结，具有很强的指导性和前瞻性，尤其是在团队协作和项目管理方面。此外，课堂上不仅仅是获取知识的场所，更是与老师和同学进行交流的机会。在答辩过程中，能更清晰地理解项目中的一些难点问题。实战后，我发现有时因为自学的盲区，错过了一些重要的知识点，比如在进行项目原型设计中对架构模式设计烦恼很久，而这些恰恰是课堂上老师会重点讲解的内容。

问题2：如何区分一个好的程序员和不好的程序员呢？
再次回答：好的程序员不仅仅是技术能力强，更重要的是他们能在团队中创造价值。他们能快速理解需求，主动沟通，帮助团队解决瓶颈问题。而不好的程序员可能只专注于完成自己的任务，缺乏全局意识，甚至可能因为疏忽引入不必要的复杂性或问题。优秀的程序员能很好地权衡技术实现和业务需求之间的关系，而不是一味追求“技术炫技”。

问题3：程序员是否有必要为满足小部分人的需求去做软件，或者为软件添加某些功能？
再次回答：在实际项目开发中，我深刻感受到需求优先级的重要性。在开发时间有限或者极短的情况下，并不是所有小众需求都需要被实现，而是要看这些需求是否能为软件带来核心价值。例如，在最后的Bate冲刺中，项目需要考虑更多关于用户体验方面的内容。通过权衡这些需求对软件整体的影响、开发成本以及对核心用户的覆盖率，我们选择了重点实现其中部分需求，舍弃了不必要的功能。实践让我理解了“少即是多”的设计哲学——把资源集中在高价值的功能开发上，才是更高效的做法。

问题4：软件开发是年轻人的饭碗，吃的是青春饭？年纪大的程序员快速学习能力拼不过年轻程序员的时候该怎么办呢？
再次回答：年纪大的程序员虽然可能在新技术学习上速度较慢，但他们的经验和判断力往往能帮助团队避开很多坑。例如，在项目开发中遇到架构设计难题时，经验丰富的团队成员可以提出多种替代方案并进行了深入的分析，最终避免了系统性能问题的发生。因此，年长程序员的角色更像是团队的“导航员”和“导师”。而且他们也可以通过带领团队和指导新人，继续在行业中发挥重要作用。

问题5：AI辅助编程，是一个银弹么？
再次回答：说不准（），在项目开发中AI工具确实能在代码补全、错误提示、生成测试用例等方面提供很大的帮助，提升了开发效率。然而实际是它的局限性也很明显：AI常常无法完全理解需求的背景和业务逻辑，生成的代码可能在逻辑或性能上存在问题。在团队项目中，我尝试使用AI生成代码片段，但发现还是需要花费大量时间去debug和优化。由此可见，AI只是一个辅助工具，而非银弹。开发者的经验和对问题的深刻理解仍是不可或缺的。

1.3 五个阶段中学习到了什么

需求：在需求阶段我学习到了怎么系统地总结用户的需求，在实践中使用了用例图等，清楚地梳理了用户的核心需求与非核心需求。在结对编程的需求阶段交流中，发现沟通的重要性，特别是在澄清模糊需求和统一团队目标时。

设计：在设计阶段我学习到了从系统整体的角度出发，采用模块化设计原则，提升系统的可扩展性和可维护性。并且熟练掌握了UML图的绘制（如类图、时序图、活动图等），并应用它们在团队中高效沟通设计方案。

实现：在实现阶段的结对项目和团队项目中我学习到了遵循代码规范和使用代码版本管理工具（如Git）进行多人协作开发，虽然不是技术上的提升，但是这为之后工作上的协作打好了基础。在开发过程中，我学习到了技术栈中的核心框架（如Spring Boot、Vue），并掌握了如何快速搭建开发环境。在遇到问题时，通过查阅文档、调试，提升了定位和解决问题的能力。

测试：在测试阶段中我学习到的部分较少，但是在上课中了解到了测试主要在于想方设法去搞垮网站，这个观点让我受益匪浅。

发布：在发布阶段中我进行了对用户反馈的收集与分析，通过用户反馈，进一步优化系统。

1.4 项目的理解和心得

在团队项目的前期中关于项目的核心理念做了很多设想和设计，也与组员进行了激烈的讨论，发现不同的人的侧重点都不同，我觉得在这种情况下可能需要舍弃自己的一部分想法为集体项目的利益考虑，更功利一点，在这样做之后，大家一起协作完成项目，最后的结果也仍然符合最初的理念并且有好的效果。

1.5 自我评分对七大课程目标的掌握程度

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

92%
通过课程学习和项目实践，我对软件工程师的职业道德有了深刻理解，包括如何平衡商业目标与用户利益，遵守知识产权法规等。此外，我更加清楚软件产品对社会、文化和健康的影响，并在项目中尝试将这些理念融入开发过程，例如在功能设计中注重用户隐私保护。
目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。

88%
在团队项目中，我能熟练提取出用户的需求，但是使用了UML、需求规格说明书等工具来表达需求的方面还需要加强。
目标3：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。

88%
在实践中我完整经历了从架构设计到组件开发的全过程，掌握了设计原则和体系结构建模工具。但是在设计的专业性方面还需要加强，这可能需要更多经验。
目标4：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。

85%
在测试方面涉及不多，，需要进一步提升对复杂系统的评测能力。
目标5：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。

90%
通过项目实践，我明白了使用文档交流的效率较高，并且熟悉了需求规格说明书、系统设计说明书和测试报告的撰写，并能够通过文档清晰地表达设计思路。
目标6：具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。

86%
在结对编程中有涉及更多，团队编程中主要由组长负责这方面。
目标7：能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。

86%
在结对编程中有涉及更多，团队编程中主要由组长负责这方面。

二、个人技术总结

个人技术总结

三、软件开发模式

3.1 关于我参与的项目

我参与的项目名为“码农物语”，是一款基于算法应用的2D像素模拟经营类游戏，旨在通过趣味的游戏机制让玩家体验算法在解决实际问题中的作用，同时结合像素风格的美术设计，为玩家提供沉浸式的模拟经营体验。
我在项目中主要担任后端和美工的角色，在美工方面中遇到的主要难题是对美工的像素动画部分不够熟悉，并且使用的绘图软件国内相关教程较少，解决的方式是在youtube上尝试搜索，发现关于这个软件的教程不少，于是问题解决。在后端开发遇到的主要问题是对C#的掌握不足，在撰写脚本时效率较低，在组员的帮助下以及在自己的学习后，后期编写的效率得以提高。

3.2 对软件开发模式的思考

3.2.1 项目采用敏捷开发 Scrum框架

该种软件开发模式的优点：

高效的团队协作：
每日站会使团队成员能够快速同步进展，发现问题并及时调整。角色分工明确（如 Scrum Master 和 Product Owner），促进团队高效合作。
灵活应对需求变化：
敏捷开发允许在每个 Sprint 结束后调整需求和目标，这使我们能够及时响应新的想法或反馈。例如，在alpha冲刺时玩家测试后提出了关于界面交互的建议，我们在下一 Sprint 中优先处理了这些问题。
快速交付可用成果：
通过分阶段完成和交付，每个迭代都能产生一个可用的功能模块，便于我们在开发过程中进行用户测试并验证功能效果。

该种软件开发模式的缺点：

对团队协作要求高：
Scrum 强调团队协作和频繁沟通，若团队成员分工不均或沟通不畅，可能导致任务延误或资源浪费。
对需求不确定性的依赖：
如果需求在开发初期并不清晰或频繁变化过快，可能会导致反复重构，影响开发效率。

对项目开发效率、团队协作和交付的影响

开发效率：
Scrum 框架通过小步快跑的方式提升了整体效率。由于每个 Sprint 都有明确目标，任务划分清晰，团队成员可以专注于当前阶段的工作，减少了大规模重构的风险。
团队协作：
每日站会和迭代回顾加强了团队内部的沟通，成员间能够及时了解彼此的进展并互相支持。我们团队在像素美术与算法逻辑的结合上，通过频繁沟通和快速反馈实现了高效协作。
最终交付：
分阶段交付的方式使得游戏在开发早期就具备一定的可玩性，方便进行用户测试并及时调整。最终交付的产品不仅符合预期，还融入了玩家反馈的优化点。

3.2.2 不同开发模式的对比与适用场景

开发模式
瀑布模型	传统的线性开发模式，适用于需求明确、变更较少的项目，比如如政府系统、工业软件。优点是开发流程清晰，文档详尽，但缺点是无法灵活应对需求变化。
敏捷开发（Scrum）	适用于需求变化较快、需要频繁交付和用户反馈的项目，比如如游戏开发、移动应用。优点是灵活、迭代快，缺点是对团队协作和需求管理要求较高。
DevOps	强调开发与运维的结合，适用于需要持续交付和高可靠性的项目，比如大型互联网平台、云服务。优点是交付速度快、可靠性高，但需要强大的自动化工具支持。

3.2.3 对软件开发模式选择的思考

我认为软件开发模式选择首先需要根据其项目的特点，如上面的不同开发模式所适用的场景，选对了开发模式，开发效率会更高。同时也要根据项目开发团队的大小规模与经验，小型团队或经验不足的团队可能难以实施复杂的开发模式，Scrum 对团队协作的要求较高，而瀑布模型则更易于管理。还需要考虑到项目开发的时间要求，项目时间紧迫且需要快速交付功能，敏捷开发是较优选择，若项目需要长时间维护，DevOps 的持续集成和部署能力会更有优势。

...全文