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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	掌握软件开发的理论、方法、技术和工具，具备系统化、规范化和可量化的软件开发能力
这个作业在哪个具体方面帮助我实现目标	总结收获，巩固自己的能力

一、问题解答

问题一：如何确定 MVP（最小可行产品）的最小功能集？

核心功能的识别标准：

1. 是否解决了用户最迫切的问题？

   • 从“用户痛点”出发，而不是“产品逻辑”出发。
   • 举例：Airbnb 最初的 MVP 只是一个网页 + 支付入口，验证“有人愿意花钱住别人家”。

2. 是否影响了用户的留存和转化？

   • 使用“用户旅程图（User Journey Map）”找出最关键的步骤（如注册、下单、付费）。
   • 用户完成目标任务所必需的“路径”功能，称为核心功能。

3. 是否可以“度量”或“验证假设”？

   • MVP 的目标是验证核心假设（例如：用户是否愿意为XX功能付费），非完成产品。
   • 功能是为了试错，不是为了完备。

问题二：任务估计过长应拆分，但如何不破坏任务完整性？

一、什么时候需要拆分任务？

• 超过1-2人天（8-16小时）开发量，需拆分，否则不便于估算和管理。
• 任务进度不可见、难以追踪、难以验收。

二、拆分时保持完整性的技巧：

1. 按“功能目标”而不是“技术子模块”拆分：

   • 错误拆法：页面拆成“前端UI”、“后端接口”、“数据库结构”。
   • 正确拆法：按“实现用户登录功能”、“实现支付流程”等功能场景拆分。

2. 保持“可交付”、“可测试”、“可演示”的粒度：

   • 每个子任务都要能单独部署、测试、用户体验。
   • 如果一个拆分子任务无法独立运行，则说明它破坏了完整性，应重新合并。

问题三：Bug 的定义是否应更严谨？

书中对 Bug 的定义是从用户视角出发的：“行为 ≠ 预期”，这在实践中确实太泛化。

更严谨的定义：

Bug 是指软件未能满足其规范、用户故事、或在主流使用路径下出现非预期行为的缺陷。

分类方式可以更清晰：

• 功能性 Bug：违反规格说明或设计意图（如点击按钮无反应）。
• 可用性 Bug（Usability Issue）：软件行为合理但用户难以理解或使用（如滑动手势不一致）。
• 兼容性 Bug：在不同平台/设备下表现不同（比如某型号手机闪退）。
• 环境 Bug：依赖项（网络、数据库）异常导致行为出错。

问题四：单元测试是否必须由最熟悉代码的人来写？

书中观点强调的是熟悉代码可以更快写出覆盖面广的测试，但并非排他。

多种测试职责划分方式并存：

1. 开发者写单元测试：

   • 对模块理解最深，适合写“正向路径”、“边界值”、“内部接口”的测试。

2. 测试人员/他人写测试：

   • 更可能发现“盲点”、“误解”、“意外输入”。
   • 实际项目中常通过 Peer Review、Code Review、Pair Testing 等方式交叉验证。

更合理的做法是：

• 开发者写基础测试 + 框架；
• 独立测试人员或团队补充覆盖盲点和异常路径；
• 对关键模块采用“测试双写”制。

问题五：结对编程是否只是理论可能？

结对编程（Pair Programming）确实在实际中有适用条件：

适合的场景：

• 学习型任务、难度高的任务、关键模块开发。
• 人员不稳定，需防止“知识孤岛”。
• 新人入职、代码重构、写测试代码等。

结对的类型：

1. Driver–Navigator 模式：一人写，一人思考、审核、引导。
2. Expert–Novice 模式：高低配，适合培养新人，但必须“教学愿意 + 氛围宽松”。

解决弊端的方法：

• 结对轮换机制：每隔一段时间轮换搭档，避免依赖和“教不会”困境。
• 精细任务分解 + 角色互换：通过合理拆分子任务，两人可交替担当 Driver。
• 绩效考核以团队产出为主：降低因分工不均而导致的心理不平衡。

不是所有项目都需要结对编程，但在合适的时机、配合良好的团队文化下，它能带来显著的知识共享和质量提升。

二、在实践中学习的知识点

需求阶段 - 跨平台需求分析

通过实际项目深入理解了如何平衡三端（iOS/Android/Web）的功能一致性需求与平台特性差异。我们采用用户故事地图方法，标注每个功能的跨平台适配要点，发现Web端对路由管理和SEO有特殊要求，而移动端更关注手势交互和性能表现。

设计阶段 - 响应式UI架构

在实践中掌握了Flutter的多维度适配方案：使用MediaQuery处理设备尺寸差异，实现平台特定UI，结合LayoutBuilder构建弹性布局。最大的收获是认识到设计系统的重要性，我们建立了统一的DesignToken管理系统。

实现阶段 - 状态管理演进

项目从简单的Provider起步，随着复杂度增长逐步升级到Riverpod+StateNotifier。深刻体会到良好的状态管理应该：业务逻辑与UI解耦、支持可测试性、便于状态持久化。我们最终形成了分层状态管理规范。

测试阶段 - 自动化测试体系

建立了三层测试体系：单元测试、Widget测试、集成测试。特别重视Golden Test确保UI一致性，并配置了CI自动执行测试矩阵。

发布阶段 - 持续交付流水线

搭建了完整的CI/CD流程：通过Melos管理monorepo，GitHub Actions执行测试->构建->发布。最复杂的部分是实现多环境配置管理，以及处理各应用商店的审核要求差异。

维护阶段 - 性能监控优化

建立了完整的监控体系：使用Firebase Crashlytics收集异常，通过Performance Monitor跟踪关键指标。定期进行内存泄漏检测和渲染性能优化，形成了版本健康度评估机制。

三、个人心得

在个人项目中，我学会了克制需求膨胀，用MVP思维聚焦核心功能。结对编程让我深刻体会到代码规范的重要性，以及知识共享的高效。团队项目则教会我用流程保障质量，比如CI/CD和代码审查。最大的认知转变有三点：1）好代码不是"能跑就行"，而要易于维护；2）技术债务越早偿还成本越低；3）文档和沟通的投入总会获得超额回报。软件工程的精髓在于平衡——在理想设计与现实约束间，在个人效率与团队协作间，在不断创新与稳定交付间找到最优解。