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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	掌握软件工程的基础知识，开发出一款功能完善，受人欢迎的软件
这个作业在哪个具体方面帮助我实现目标	总结课程中学到的知识并将其应用到今后的软件开发实践中去

链接到以前提问题的博客

[I.1] 个人作业：阅读和提问

问题一：单元测试由谁来写更有效？

最佳实践是：开发者写单元测试，测试人员写集成/系统测试。

单元测试的目标是验证最小逻辑单元的正确性（如函数、类）。开发者最了解模块的预期行为，能写出精细的测试。需要注意的是，虽然开发者可能存在“认知盲区”，但这更适合通过Code Review + 覆盖率分析来弥补，而不是转交给不了解代码逻辑的测试人员。

问题二：Sprint结束时是否应强制终止未完成任务？

敏捷核心原则强调“可预测节奏”，固定Sprint时间框架是为了避免延期失控，提高节奏感。

未完成任务应进入Backlog并重新评估优先级。 设置“修正期”看似合理，但可能破坏节奏和团队预期。若频繁出现“快完成却被切断”，则应反思估算、拆分任务的准确性。

问题三：测试人员应何时介入项目开发？

测试早期介入是推荐策略（Shift Left），但“介入不等于写测试用例”。
初期测试人员应：

• 参与需求评审、制定验收标准。
• 与开发讨论测试策略、风险点。
• 编写测试计划/测试点框架，但用例设计可延后至功能稳定。

问题四：界面简化 vs 功能完整性的矛盾如何平衡？

简洁并不等于删减功能，而是合理分层展示功能。简洁界面的关键在于：常用功能优先展示，复杂功能有序隐藏。这符合“渐进披露”原则，即：只在用户需要时，才逐步呈现更多复杂选项。

同时，功能优先级的判断应基于用户数据与场景分析。为了确定哪些功能应“暴露”而哪些可“隐藏”，可以参考：

• 用户访问频率（点击热图、行为日志）；
• 用户群体画像（新手 vs 高阶用户）；
• 使用场景（高频快捷操作 vs 低频配置项）；
• 问卷调查或用户访谈反馈。

此外，通过用户角色和模式切换实现“分层界面”。例如某些图形设计软件、开发工具提供“简洁模式 / 专业模式”两套界面，满足不同层级用户的需求。这样的设计可以有效缓解“新手友好”与“高阶效率”之间的矛盾。

问题五：测试计划是否应一次性定完？如何兼顾灵活性？

在传统瀑布式开发中，测试计划往往在项目初期就制定得非常详细，作为整个测试活动的主线。但在敏捷开发环境中，这种“定一不变”的测试计划不再适用，取而代之的是一种“持续更新、动态调整”的测试计划机制。

也就是说，测试计划在敏捷项目中不是一次性定完的“静态文件”，而是一个“指导性、迭代性”的活文档。

初始阶段仍然需要制定测试计划的“骨架”，包括：

• 测试目标与范围；
• 测试角色与资源安排；
• 工具、环境、时间安排；
• 质量指标（如缺陷密度、通过率）；

这部分内容可作为团队测试工作的“导航图”，确保所有成员在同一方向上协作，具备一定的可预期性。

每个Sprint开始时，团队可以结合当前需求调整测试重点、测试用例设计、自动化范围等。特别是在遇到需求变更、技术方案调整或突发Bug时，计划也应同步更新。

问题六：PSP是否适合所有工程师？

PSP适合：

• 初级工程师对提升时间管理、自我反思能力存在需求的场景；
• 注重流程改进的研发环境；
  不适合：
• 快节奏、迭代为主的团队；
• 短期项目或频繁需求变化场景；
  在敏捷下，可以保留PSP的“记录时间、缺陷自检”等精华，而不拘泥于完整形式。

学到的知识点

需求阶段

在需求阶段，我学到的最重要的知识是：如何从用户的角度去表达和分析需求，而不是仅从技术角度理解功能。这样的表达方式不仅更贴近用户思维，也有助于团队在开发前就统一对功能价值的理解，避免“做出来不是用户想要的”的问题。

设计阶段

设计阶段让我理解到，合理划分模块、明确每个模块的职责，可以大幅提高系统的可维护性和可扩展性。比如使用MVC架构可以将展示逻辑、业务逻辑和数据逻辑分离，便于协作开发和后期修改。

实现阶段

在编码实现阶段，学到的核心知识点是：如何通过 Git 分支管理进行多人协作。通过合理使用分支，我们能同时开发多个功能而不互相干扰，也能追踪代码变更，提高代码质量。

测试阶段

测试阶段的关键收获是：自动化测试能极大提升回归测试效率与系统稳定性。使用工具实现单元测试、集成测试，不仅节省时间，还能帮助我们及时发现和定位问题。

发布阶段

在发布阶段，我接触到了CI/CD流程，了解到如何将代码从开发环境快速、安全地部署到生产环境。
借助GitHub Actions等工具，我们实现了自动构建、测试、部署，提升了上线效率。

维护阶段

维护阶段的最大收获是学会用工具追踪Bug。同时我认识到不仅需要修复已知问题，更要关注代码的可读性、文档完善程度，以及未来可能的扩展性，从而实现“可持续维护”。

心得

在学习软件工程这门课程的过程中，我通过个人项目、结对编程和团队协作的实践，逐渐从“写代码”上升到了“做项目”和“做产品”的视角，对软件开发的全过程有了更系统、更现实的理解。

在团队项目中，我深刻体会到了软件工程方法论的意义。我们通过每日例会、燃尽图追踪进度，借助Git进行版本控制，使用看板来管理任务。这些流程看似“繁琐”，但实则极大提升了协作效率，也帮助我们从“做功能”转向“交付产品”。