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

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

之前的博客：[I.1] 个人作业：阅读和提问

问题 1：如何设计有效的单元测试用例，而不仅仅是追求高覆盖率？

在学习过程中，我渐渐明白了，高覆盖率并不等于高质量测试。一开始我也以为测试写得越多越好，但后来通过阅读书中对测试策略的讲解，结合自己查资料时看到的一些案例，我开始注意到，真正有价值的测试是在边界条件和异常场景下能发现问题的那些。特别是了解了“等价类划分”“边界值分析”等原则后，我意识到测试设计应该围绕代码的意图和关键路径展开，而不是单纯刷行数。测试是为了保障逻辑正确，而不是为了看起来好看。

问题 2：如何在团队中有效实施结对编程，避免效率下降？

刚接触结对编程时，我确实担心两个人一起写代码会不会效率低，但随着对这部分内容的深入学习，以及参考了一些别人分享的实践经验，我慢慢认识到，结对编程的关键不在于“两个人一起写”，而在于“如何配合得高效”。比如，明确分工、适时切换角色，还有对任务的选择，都会影响效果。通过这些了解，我对结对编程的适用场景和方式有了更清晰的认识，也不再一味地把它当作提高质量的万能钥匙，而是看情况灵活运用。

问题 3：如何在敏捷开发中有效管理频繁变化的需求？

起初我对敏捷开发中“变化是常态”的观点感到有点焦虑，觉得变化太多会打乱节奏。但在进一步阅读相关章节、查资料了解实践经验后，我慢慢体会到，敏捷真正强调的是“有节奏地应对变化”，而不是随波逐流。通过理解迭代计划、用户故事管理等方法，我意识到只要优先级分清楚、反馈足够及时，需求的变化反而能帮助我们更快地对齐用户价值。敏捷不是乱，而是快中有序。

问题 4：如何在职业发展中平衡“全栈化”与“专精化”？

对于“全栈”还是“专精”的选择，我一开始确实有点犹豫，但在学习过程中，通过书中对不同成长路径的讨论，加上我自己查阅的一些职业发展建议，我逐渐理清了思路：早期可以广泛接触不同领域，帮助自己建立整体技术视野；而后续再根据兴趣和优势去深入一个方向，形成自己的核心能力。不是非此即彼，而是阶段不同重点不同。这个认识让我在思考未来时不再焦虑，而是更有方向感。

问题 5：如何在需求明确的项目中有效应用瀑布模型？

我原本以为瀑布模型已经“过时”了，但在深入阅读后，我发现它其实在某些特定场景下仍然非常有效。特别是面对需求稳定、变动较小的项目，瀑布模型的阶段性推进反而更利于控制进度和质量。通过查阅资料和对比不同开发模式的优缺点，我逐渐认识到，关键不在于用不用敏捷，而在于用对了什么。瀑布并没有错，只是要选对场合，做好前期规划和阶段审查，它依然是一种值得借鉴的方法。

需求阶段：学会用用户故事表达需求

在团队项目中，我们用“作为一个……我希望……”的格式整理功能，帮助我们从用户角度理解需求，避免只从开发者视角出发。

设计阶段：理解高内聚低耦合

结对编程时，我们尝试把功能划分到不同模块，发现高内聚低耦合能让代码更清晰，也更容易后期维护。

实现阶段：掌握版本控制协作方式

在团队开发中，我们用 Git 分支协作，学到了如何用 pull request 管理合并流程，避免多人开发时互相冲突。

测试阶段：理解测试用例设计原则

写单元测试时，我体会到边界值、异常情况才是测试的重点，而不是一味追求覆盖率。

发布阶段：接触自动构建与部署流程

我们使用了简单的自动构建脚本，让项目在提交后能自动部署到测试环境，发布过程更规范、更可靠。

维护阶段：意识到技术债和文档的重要性

在回顾项目代码时，发现缺注释、结构混乱的地方最难维护，也因此认识到写好文档和代码整洁的必要性。

心得体会

这门课让我真正体会到“软件工程”不仅是理论知识的积累，更是一种实践中的不断调整和反思。很多知识点原本只是书上的概念，但一旦放到实际项目中，就变得鲜活具体。比如，需求写不清团队就容易误解，设计不合理后期就维护困难，测试不到位 bug 就频出……这一切都让我意识到，工程化思维的价值在于可协作、可维护、可持续，而不是“一次性完成任务”。通过个人项目、结对编程、团队合作，我不仅掌握了工具和流程，更培养了面对复杂问题时系统性思考的能力。这种“在做中学”的过程很不容易，但回头看，每一次“踩坑”和反思，都是最宝贵的收获。