| 这个作业属于哪个课程 | 202501福大-软件工程实践-w班 |
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 完成软件工程实践总结 |
| 其他参考文献 | 阿里巴巴Java开发手册、Git Flow工作流指南、敏捷开发实践 |

目录

一、回首过去

在这门充满挑战与收获的《软件工程实践》课程中，我经历了一场从理论认知到实践能力的深刻蜕变。当回顾这学期的学习历程，我发现自己不仅在技术能力上得到了显著提升，更重要的是对软件开发的系统工程思维有了更全面的理解。这种成长不仅仅体现在代码编写能力的增强，更体现在对软件全生命周期管理的认识深化。

一、深入思考的问题与重新解答

问题一：如何在敏捷开发中平衡需求变更与项目稳定性？

最初的理解困惑：

在课程初期，我单纯认为敏捷开发就是“快速响应变化”，但当真正面对团队项目中频繁的需求变更时，我们陷入了混乱——功能不断增删改，代码结构日趋混乱，测试用例难以维护。

逐步厘清的过程：

1. 理论学习突破：通过阅读《敏捷宣言》解读材料，我理解了敏捷的四个核心价值中，“响应变化高于遵循计划”并不等于“随意变化”，而是要在“个体与互动”、“可工作的软件”等价值中寻找平衡。

2. 实践中的反思：在团队项目的第三次迭代中，我们遭遇了严重的技术债务问题。通过和指导老师的讨论，我意识到问题在于我们缺乏有效的变更管理机制。我们随后引入了以下改进：

   • 变更控制板：所有需求变更必须经过产品负责人和技术负责人共同评审

   • 影响分析模板：每次变更前评估对现有功能、测试、文档的影响

   • 技术债务追踪：将重构任务明确列入迭代计划

当前的理解：

敏捷开发中的“拥抱变化”应当是“有序拥抱变化”，需要通过建立适当的流程和规范，在灵活性和稳定性之间找到最佳平衡点。变化应当是经过深思熟虑、评估影响后的理性决策，而不是随意的妥协。

问题二：团队协作中如何确保代码质量的一致性？

原有困惑：

在结对编程阶段，我以为只要双方沟通顺畅就能保证代码质量。但在团队项目中，面对8人协作、模块相互依赖的复杂情况，简单的沟通明显不足。

解决路径：

1. 流程制度建设：建立了代码审查Checklist，包含：

   • 功能完整性

   • 代码规范性

   • 测试覆盖率

   • 文档完整性

2. 意识培训：通过定期举办会议，分享优秀代码模式和常见反模式，逐步形成团队的质量共识。

新的认识：

代码质量保障是一个系统工程，需要“工具+流程+文化”三位一体。单纯依赖个人能力或简单工具，都难以持续保证质量。

仍存疑问：

我们在快速迭代的压力下，如何平衡代码质量检查和开发效率？我们在实践中发现，过于严格的质量门禁有时会拖慢进度，这个平衡点的量化标准仍需探索。

新产生的问题：

如何建立适合小型团队的质量度量体系？

二、各阶段最大收获

1. 需求阶段：学会挖掘真实需求

最大的收获是掌握了需求层次分析法。通过用户访谈、竞品分析、场景建模等方法，我学会了区分用户的“表面需求”和“本质需求”。在团队项目中，我们最初接收到的需求是“需要一个任务管理功能”，但通过深入分析，发现用户真正的痛点是“跨团队协作时的信息同步困难”。这个认识转变让我们重新设计了整个协作流程。

2. 设计阶段：理解架构权衡的艺术

学会了架构决策记录的方法。在技术选型时，我们不再是简单地选择“最新”或“最流行”的技术，而是系统地评估各个方案的优缺点、约束条件和长期影响。例如在选择数据库时，我们通过ADR模板记录了考虑因素、备选方案、决策理由和预期后果，这种规范化决策过程大大减少了后期的技术债务。

3. 实现阶段：掌握工程化开发实践

最大的提升是测试驱动开发的实践能力。从最初的抵触到后来的主动运用，我深刻体会到“红-绿-重构”循环的价值。在实现用户权限模块时，通过先写测试用例，我们发现了几处潜在的边界情况，避免了后期修复的高成本。

4. 测试阶段：建立质量保障思维

学会了分层测试策略的设计。我们构建了从单元测试、集成测试到端到端测试的完整金字塔，并且明确了各层的覆盖目标和执行频率。更重要的是，我理解了“测试不是QA的工作，而是每个开发者的责任”这一理念。

5. 发布阶段：认识持续交付价值

掌握了部署流水线的搭建和优化。最初的部署，我们经历了部署失败、环境不一致、回滚困难等各种问题，最终建立起可靠的发布流程。这个过程让我深刻理解了“可重复、可靠、快速”的发布能力对产品迭代的重要性。

三、项目经历心得

个人项目：从“能运行”到“好代码”

个人项目让我学会了自我驱动和时间管理。最大的收获是编码规范的建立——从一开始的随意命名到形成自己的命名规范、注释规范。我创建了个人代码模板库，这个习惯延续到了后续所有项目中。

结对编程：沟通的艺术

与搭档的合作让我认识到，技术能力的差异可以通过良好的沟通弥补。我们建立了“驾驶员-领航员”轮换制，并制定了“15分钟原则”——当遇到问题时，如果15分钟内无法解决，必须寻求外部帮助或转换思路。这种模式显著提高了问题解决效率。

团队项目：系统工程的实践

在8人团队中，我担任了后端技术负责人的角色。除了技术实现，我更需要考虑：

• 技术债务管理：定期评估和规划重构

• 知识传递：确保关键模块至少两人熟悉

• 风险控制：识别技术风险并制定缓解策略

我最深刻的体会是：技术决策必须服务于业务目标。我们曾为追求技术先进性而选择了一个较新的框架，结果在集成时遇到了兼容性问题，延误了进度。这个教训让我明白了“合适比先进更重要”。

四、课程目标掌握程度自评

目标1：职业道德与社会责任（85分）

通过课程中的伦理案例分析和社会影响讨论，我认识到软件产品不仅是技术产物，更是社会产品。在团队项目中，我们特别注意了用户隐私保护和数据安全。但相比于业界实际经验，我的理解还停留在理论层面。

目标2：需求分析能力（90分）

掌握了从需求收集到规格说明的全套方法工具。特别在用户故事地图和验收标准编写方面有显著进步。在团队项目中，我主导了三次用户访谈，成功识别了三个关键用户痛点，这些发现直接影响了产品方向。

目标3：系统设计能力（80分）

能够完成从架构设计到模块设计的完整过程。掌握了UML建模、API设计等技能。但在设计模式的应用和架构模式的选择上，经验仍显不足，有时会过度设计或设计不足。

目标4：技术评估能力（85分）

通过多个技术选型决策，我学会了系统评估技术方案的方法。建立了包含性能、可维护性、社区支持等维度的评估矩阵。能够进行技术可行性分析和风险评估。

目标5：文档规范能力（80分）

熟悉了软件工程各阶段文档的编写规范和标准。在团队项目中负责了和《API文档》的编写和维护。掌握了Markdown、Swagger等工具的使用。

目标6：团队协作能力（85分）

经历了完整的团队协作周期，掌握了Git协作流程、代码审查、站立会议等实践。学会了在团队中有效沟通和协调，但在冲突处理和跨职能协作方面仍需提高。

目标7：项目管理能力（80分）

能够使用燃尽图、看板等工具进行项目跟踪，掌握了任务分解和估算方法。但在风险管理和资源调配方面经验有限，对复杂项目的多维度管控能力有待加强。

二、立足当下

在学期初制定的学习路线中，我重点关注了后端开发技术和工程化实践。目前已完成：

• Spring Boot框架的深入学习

• 数据库优化和缓存策略

• 容器化部署和CI/CD流水线

• 微服务架构基础概念

在团队开发中，我担任后端主要开发角色，解决了以下关键技术问题：

1. 多用户并发时的数据一致性问题

2. JWT令牌的安全管理机制

技术博客

1|基于 AES + Base64 的密码加密工具类实现与优化

2| 概述：基于AES+Base64可逆加密方案，解决了跨平台密钥一致性和URL安全传输问题，适用于非密码类敏感数据加解密。

第三部分：软件开发模式

项目概述

项目名称：规巢宿舍管理系统
项目目标：为宿舍管理提供高效的工具

技术栈：

• 后端：Spring Boot + MyBatis Plus + MySQL

• 部署：Docker + Jenkins + Nginx

关键决策：

• 采用微服务架构解耦用户服务和任务服务

• 使用WebSocket实现实时通知

挑战与解决方案：

1. 数据一致性挑战：在分布式环境下，用户状态更新延迟。我们通过事件驱动架构和最终一致性模式解决。

2. 性能瓶颈：文件上传服务在高并发时响应慢。通过分块上传和CDN加速优化。

软件开发模式分析

采用的模式：敏捷开发

我们采用Scrum，形成了适合8人小团队的混合模式：

具体实践：

• 每日站立会议

• 每迭代一次回顾会议

优点体现：

1. 开发效率：通过短周期迭代，我们能够快速响应变化，平均每迭代交付4-6个用户故事

2. 团队协作：看板让工作透明化，减少了任务等待和资源冲突

3. 质量保障：每个迭代都包含完整的测试周期，质量内建于过程

遇到的挑战：

1. 需求蔓延：初期因缺少严格变更控制，导致范围不断扩大

2. 技术债务积累：为追求交付速度，部分代码质量妥协

不同模式对比与选择建议

实践思考与建议

我的理解：

软件开发模式不是教条，而是服务于团队和项目的工具。关键在于：

1. 适应性：根据团队特点、项目阶段动态调整

2. 务实性：选择能解决实际问题的实践，而不是追求“正统”

3. 度量性：建立反馈循环，持续评估模式效果

我的领悟：

1. 起步阶段：不要过度设计流程，先建立最基本的迭代节奏和沟通机制

2. 成长阶段：当团队规模或项目复杂度增加时，逐步引入更多工程实践

3. 成熟阶段：定期回顾和优化开发流程，避免僵化

最好的开发模式是能够持续学习和改进的模式。我们进行了回顾，基于数据和团队反馈调整了工作流程，这比最初选择“正确”的模式更重要。软件工程不仅是技术活动，更是社会技术系统，需要平衡人的因素、技术因素和过程因素。
这门课程让我从一个单纯的“编码者”开始向“软件工程师”转变。我开始用系统思维看待软件开发，理解技术决策背后的权衡，重视过程的价值而不仅仅是结果。这段旅程的收获将伴随我未来的每一个项目，每一个技术决策。软件工程之路，我才刚刚起步，但方向已明，步履坚定。