[I.3] 个人作业：结课总结

[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	掌握软件工程的核心技能，完善个人技术栈，提升开发效率与项目质量。
这个作业在哪个具体方面帮助我实现目标	回顾整个《软件工程》课程的开发过程，在总结中提高对敏捷开发等概念的理解
我之前提问的博客	[I.1] 个人作业：阅读和提问

一、提问回顾与回答

问题一:如何应对频繁的需求变更?

解决方式

通过查询资料和实践，得出下列解决方法：

• 透明沟通：每日站会说明变更原因
• 可视化影响：用图展示需求变动对进度的冲击
• 预留缓冲：每轮迭代保留 20% 时间应对突发需求

问题二：过早优化的判断标准是什么？

解决方式

通过实践，得出下列判断标准：

• 缺乏可靠的数据来证明存在明显的性能瓶颈
• 优化后代码更复杂，如引入新依赖或可读性下降

问题三：单元测试只能由代码作者写吗？

解决方式

通过查询资料，得出结论

结论：单元测试不应该只由代码作者来写

理由

• 认知盲区：代码的作者易陷入 "自证正确" 思维陷阱，倾向于验证预设路径而非探索异常分支
• 场景覆盖不足：对业务上下文的理解偏差可能导致遗漏关键用例，如边界值和安全漏洞等
• 质量保障悖论：测试与开发职责未分离时，“确认偏误”会降低缺陷发现效率

问题四：如何缓解结对编程中的压力？

解决方式

通过实践和查询资料，得出下列解决方法：

• 分段式结对
  采用 25分钟聚焦编程+5分钟自由讨论 的番茄钟模式，降低持续紧迫感；
• 角色动态轮换
  每30分钟强制切换"驾驶员/领航员"角色，避免单方长期处于被动审查状态。

问题五：PM是否应该完全不参与开发与测试？

解决方式

通过实践和查询资料，得出结论：

结论：PM应轻量参与技术环节

• 开发环节：参与架构评审，但不需要写核心代码；
• 测试环节：参与验收测试，模拟用户验证流程。

二、各阶段知识点总结

阶段	知识点
需求	通过用户故事地图（User Story Mapping），学会了区分“基本需求”“期望需求”和“兴奋需求”，明确核心功能边界，避免范围蔓延
设计	采用模块化设计，通过接口抽象降低耦合度，为未来功能的扩展预留了技术空间
实现	通过Linter工具和代码格式化工具统一代码风格，结合静态分析检测潜在缺陷），提升代码可读性与可维护性
测试	理解单元测试（占比70%）、集成测试（20%）、UI测试（10%）的投入比例，避免过度依赖耗时且脆弱的端到端测试。
发布	使用自动化工具，让项目在提交后自动部署，规范化了发布流程
维护	使用SonarQube等工具对代码质量进行持续监控，平衡新功能开发与系统健康度

三、个人心得体会

个人项目

领悟了"先跑通再优化" ：初期过度设计拖累进度，改为先实现基础版本后迭代，效率翻倍

结对编程

两人结对编程时很可能陷入等待对方提出想法的“死锁”处境，需要有人善于引导思考，才能实现高效的结对开发

团队项目

在团队开发中一定要始终明确自己的开发任务，并在开发时积极思考架构是否方便将来的迭代