114
社区成员
发帖
与我相关
我的任务
分享课程总结：在项目实践里“做中学”
第一部分：课程回顾与总结
1.每个阶段收获的知识或能力
在本课程学习的需求/设计/实现/测试/发布五个阶段中：首先，在需求阶段，我学会了绘制用例图，编写需求规格说明书，理解了NABCD在需求分析环节对软件的重要作用，软件的设计要考虑用户的视角，在实际的项目需求分析过程中需要和客户充分沟通再决定软件策略。
在设计阶段，我学会了分析软件模块和类之间的关系，相比于过去在确定设计需求后直接上手编程，我理解了设计环节的重要性，拥有一个清晰的类图来辅助项目的体验要远优于没有类图的情况，尤其是在规模偏大的项目里，类图的出现协助了开发人员分模块处理软件的各个部分，也使得开发人员更清楚软件各个模块之间的依赖关系，从而提高开发效率。
在实现阶段，由于是首次面对这样规模的项目，我认识到编程规范给团队开发带来的影响，携带说明与注释的代码段可以大大减少同组同学的阅读压力。并且学会了利用vs code软件里携带的各类插件辅助开发，增加效率。
在测试阶段，我首次体验了AI技术员协助的自动化测试，通过AI能够更快排查项目中的错误与定位代码内部矛盾，大大提升了测试的效率，同时AI也会提供一定的项目优化建议与代码参考，对于我所处项目与未来项目的程序测试阶段一定都会起到关键的作用。
在发布阶段，我认识到程序最终展示的效果可能会符合开发人员自身的设想，但是在同时关注用户的持续反馈也是很必要的，例如在我所处项目的最终测试发布上，模拟的用户提出了程序内部功能关联性可以改进的地方，这些地方是在开发阶段考虑不够深入的，在遇到这类可能出现的问题时需要我们开发人员更加注重与外界的沟通，才能更好地优化软件。
2.在项目团队中的体会与心得
在我们“到处都是搭子队”中，我本次担任的是后端开发的角色，在项目开发的前期，由于开发经验不足，特意请教了同组的同学有关于后端开发流程与模块的问题，在后端功能完成的初期经常会担心开发的功能能否正确运作，但是后来发现同组的其他同学能够及时提出指正，或者帮助修复程序里的问题，这让我体验到了项目团队给单个开发者带来的优势，能够保持一定频率的沟通，可以通过团队解决很多对于个人而言的麻烦，从而提高开发的效率与质量，十分感谢我同组的同学。
3.深入思考的问题
本次项目开发的主要问题除了技术上的问题，主要是在前期的设计与开发衔接的阶段。
基于过去自己开发小项目的思路，我认为软件开发的流程应该是线性的，各个阶段应该提前都规划好再进行开发，也就是开发模式中的瀑布模式，但是在本次开发中我接触到了更加灵活的敏捷模式，面对规模更大的项目，我一开始的想法忽略了软件客户的方面，在敏捷过程中的多次冲刺总结中，团队可以通过和用户沟通来确定项目存在的不足，对于已经实行的功能和阶段也可以再回去返工，或者对于用户的需求变化相对地改变自己的程序；另外，相对于瀑布模式，敏捷模式一个阶段内的进度是可以动态调整的，部分减轻了开发人员的工作量和压力。
对于现在软件市场的开发环境来说，我之前实施的瀑布模式唯一的优势只在于结构的清晰，但是敏捷模式却提供了更大的灵活性，降低了开发的时间和工作量成本，是有必要提前适应与熟练的开发模式。
4.总体自我评估
在本次课程学习中，我会从以下七个方面进行自我评估：
1：职业道德与社会责任：
通过课程学习，我深入理解了软件工程伦理准则，认识到软件对社会的深远影响。在项目设计中，我会主动考虑隐私保护、可访问性等伦理问题，并尝试结合当前市场需求进行思考，初步树立了负责任、向善的开发理念。
2：需求分析能力：
能够运用用户故事、用例图及原型工具进行需求挖掘与表达。在实践中，我学会了区分用户“表面需求”与“本质需求”，并通过建立流程分析模型，规范输出需求规格说明，确保与客户/用户目标一致。
3：全流程开发与设计能力：
熟悉软件开发生命周期，能够在项目实践中遵循模块化、高内聚低耦合等设计原则。通过类图、时序图、架构图等完成从体系结构到构件级的设计建模，并经历正式技术评审，初步形成了构建可靠、可复用服务组件或系统的设计能力。
4：设计评审与创新择优能力：
具备对设计模型进行质量评判的能力，能够从性能、可维护性、技术可行性等维度评估方案。在多个设计方案中，我能够通过对比分析，选择更优解，并在约束条件下进行创新性改进，平衡技术债务与项目目标。
5：文档规范与交流能力：
能够遵循标准规范，撰写需求规格说明书、设计文档及测试报告。文档结构清晰、表达准确，并能够利用图表辅助表达。通过课堂汇报和团队评审，具备了与同行进行有效技术沟通的能力。
6：团队协作与领导能力：
在小组项目中担任后端开发人员，通过定期站会、codearts仓库、线上沟通平台与成员保持同步。能够主动沟通、协调分工、化解分歧，具备组织团队协作完成任务的能力。
7：项目管理初步能力：
了解软件项目管理的核心要素，能够使用功能点估算或敏捷故事点进行工作量预估。但是在利用工具规划项目进度上还是不太熟练，可以通过版本控制与 CI/CD 工具进行配置管理加深自己的理解。
第二部分：个人技术总结
由于软件开发的需要，本学期的实践学习中并没有运用到我学习计划中提到的C/C++内容，我只能通过其他课程的算法学习积累相关的知识。在实践中更多的还是运用到sql数据库和java项目开发所需的知识。
说到最让人印象深刻的实际技术，在本次项目中，我首次接触到了spring boot。它是一个用于快速构建生产级 Java 应用程序的框架。其核心理念是 “约定大于配置”，在提供了默认配置与内嵌设置的条件下，可以给项目开发者带来很多便利。
spring boot项目的建立与环境配置：https://bbs.csdn.net/topics/620086804
概述：本技术博客意在为java项目的新手开发者提供一个便捷的开发框架spring boot，这个框架提供了默认配置和内嵌 Web 服务器，让开发者能专注于编写业务逻辑，而无需进行繁琐的初始设置。只需简单的几步，即可创建一个独立运行、功能完备的 Web 应用或微服务。
第三部分：软件开发模式
1.开发模式的选择与执行
本次项目开发中，我们团队选择使用敏捷模式进行开发，正如博客前面所言，敏捷模式是一个灵活的、动态的模式，开发人员可以随时参考用户意见对项目流程进行返工，也可以根据用户需求的变化对项目进行调整，是一个能够节省开发成本，纠错便利、开发便捷的模式。就本次的开发体验来说对我们团队提供了很大的帮助。
但是敏捷模式也有自身的缺点，就是需要客户在一些阶段的参与，如果没有用户提供建议，那么开发的流程可能不会优于其他模式。同时，这个模式也需要团队内各成员的积极协作与自律，由于开发进度灵活，会出现部分成员开发进度懈怠，导致项目最终交付延期的后果。但是由于本次我们小组内的成员都进行了有效的沟通和配合，这个缺点并没有很明显地体现出来。
2.带来的一些思考
在软件工程实践中，开发模式的选择本质是对不确定性的管理，核心取决于需求稳定性、变更成本与团队协作方式。我认为三个代表性模式及其适用场景如下：瀑布模型适用于需求绝对明确、变更代价极高的领域（如航天软件、医疗设备），它通过前期完备规划规避风险，但无法适应变化。敏捷开发是应对需求多变、需要快速验证市场的首选（如互联网产品、创业项目），它通过短周期迭代和持续反馈拥抱变化，但对客户参与和团队自律要求高。增量迭代模型则是大型系统或部分需求明确场景下的务实选择（如ERP、操作系统），它通过分阶段交付完整子系统来平衡风险与可控性。
没有最佳的模式，只有最适应当下语境的权衡。成熟的软件工程师应该根据实际的需求像工具一样熟练各种开发模式，确保所有流程都应服务于同一目标：高效、可靠地交付有价值且可维护的软件。
...全文
请发表友善的回复…
发表回复
