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

课程信息

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	系统掌握软件工程各阶段知识和技能，学会运用相关工具进行项目开发
这个作业在哪个具体方面帮助我实现目标	回顾软件工程开发，总结这学期的学习成果

过往博客链接

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

提问回顾与个人总结

学期初，我带着对软件工程理论的初步认知，提出了五个问题。如今，在亲身参与了结对项目（贪吃蛇）和团队项目（“碎星集”App）的开发后，这些问题有了更为具象的答案。

问题一：燃尽图的波动如何影响敏捷开发？

我的疑问： 在不影响敏捷开发效率的前提下，如何让燃尽图更准确地反映项目进度？

我的解答与理解：

燃尽图的波动是敏捷开发中一个常见但又让人头疼的问题，特别是在项目初期，对任务预估的不准确常常导致燃尽图非常的曲折。学期初，我曾疑惑频繁的调整是否会违背敏捷“快速迭代”的初衷。而通过这学期的团队项目实践，我发现敏捷开发的精髓在于适应变化，而非固守计划。当燃尽图出现较大波动时，我们团队并没有选择“频繁调整”，而是将重点放在以下几点来让燃尽图更准确地反映进度：

• 高频率沟通与透明化： 每日组会成为了我们团队发现问题和调整进度的重要场合。大家会主动同步自己的进度和遇到的困难，一旦发现燃尽图有异常趋势，会立刻讨论原因并商量对策。这种透明化的沟通方式让我们能及时发现问题，而不是等到问题累积爆发。
• 关注趋势而非单点： 我们不再过度纠结燃尽图的每一次小波动，而是更关注整体的下降趋势。如果趋势长期偏离，我们会深入分析原因，可能是任务量过大、团队效率下降，或是遇到了预料之外的技术难题。
• 利用历史数据优化： 随着团队项目经验的积累，我们开始回顾过往冲刺的燃尽图和实际完成情况，这帮助我们更准确地评估未来的任务。例如，某个特定类型的任务，我们发现总是比预估的要耗时，在下次估算时就会有所调整。

可以说，燃尽图的波动并非全是坏事，它能及时暴露出项目中的问题。关键在于团队如何利用这种波动，通过加强沟通透明度、关注趋势等方式，让燃尽图真正成为指导项目进度的有效工具。频繁调整不是指频繁修改计划，而是频繁地适应变化。

问题二：如何在复杂业务需求中合理应用SRP和OCP？

我的疑问： 在面对业务快速变化的情况下，如何更好地在实践中遵循SRP和OCP，以确保代码的可维护性？

我的解答与理解：

单一职责原则（SRP）和开放-封闭原则（OCP）是软件设计的基石。在贪吃蛇项目以及后续“碎星集”的复杂业务场景中，我深刻体会到完全严格地遵循这些原则是理想状态，但在实际中需要权衡与取舍。

在“碎星集”的初期开发中，我们最初为了快速上线，将笔记发布、日历和模板等多个逻辑都杂糅在一个模块里。这导致 alpha 阶段的维护时一个小改动就会牵一发而动全身，非常痛苦。而在吸取了教训后，我们开始尝试更细致地划分职责。例如，我们将用户管理、内容发布、评论交互等拆分为独立的模块或服务。我理解到，单一职责原则 SRP 并非要求模块小到不能再小，而是要关注“导致其变化的原因”。当一个模块因为两个不同的业务需求而需要修改时，它就可能违反了SRP。

进一步的，在“碎星集”App中，我们预留了多种内容推荐算法的实现。通过定义接口或抽象类，每种推荐算法都实现了这个接口。当需要增加新的推荐策略时，我们只需实现一个新的类，无需修改原有的推荐逻辑。这正是开放-封闭原则 OCP 的体现：对扩展开放，对修改封闭。

总结来看，SRP和OCP并非教条，而是指导我们进行模块化设计和抽象的原则。在快速变化的业务环境中，我们学会了根据项目的实际情况和未来可预见的变化来选择合适的职责粒度和抽象层次。通过持续重构，我们逐步优化代码结构，使其更符合这些原则，从而提高了代码的可维护性和可扩展性。

问题三：开发与测试之间的矛盾如何化解？

我的疑问： 如何从根本上解决开发与测试之间的矛盾，实现二者的平衡协作？

我的解答与理解：

学期初阅读时，书中提到开发和测试有时会相互对立，我对此深有体会。在项目实践中，由于目标不一致和信息不对称，我们团队也曾出现过开发和测试互相推诿的情况，影响了项目进度。

通过这学期的团队项目，我认识到，解决开发与测试矛盾的关键在于建立共同的目标、加强信息共享以及一些自动化流程的辅助：

• 设定共同的目标： 我们团队将bug数量、用户反馈满意度等作为开发和测试团队共同的质量目标。这意味着我们不再是“开发只管写代码，测试只管找Bug”，而是共同为产品的质量负责。当出现bug时，大家会一起复盘，而不是互相指责。这种共同的责任感大大促进了协作。
• 加强沟通与知识共享： 我们鼓励开发人员在提测前，主动向测试人员讲解本次迭代的改动点、可能的风险区域。测试人员也会及时反馈测试中遇到的问题，并提供详细的复现步骤和日志信息。这种双向的、高频率的沟通减少了信息不对称，提高了问题解决的效率。
• 自动化测试与持续集成： 我们引入了单元测试、接口测试和一些自动化测试。通过持续集成的CI/CD流程，提交代码后会自动触发测试。这意味着问题可以被更早地发现并修复，减少了人工测试的压力，也避免了后期大量的Bug修复工作。

所以说，开发与测试之间的矛盾并非不可调和。当双方都将“交付高质量产品”作为共同目标时，通过一些早期的介入和沟通共享，就能实现从“对立”到“协作”的转变，共同推动项目成功。

问题四：团队模式如何适配不同类型的项目？

我的疑问： 在项目发展的不同阶段，团队模式应如何进行调整，以更好地适应项目需求？

我的解答与理解：

学期初阅读“团队和流程”章节时，我了解到有主治医师模式、明星模式、社区模式等多种团队模式。但在实际应用中，如何根据项目特点选择和调整模式，对我来说是一个难题。

在结对编程和团队项目的实践中，我深刻体会到团队模式并非一成不变，而是需要根据项目的生命周期和具体需求进行动态调整。

以我们经历的团队项目为例：

• 项目初期（MVP期）：我们的项目是一个创新型的推送APP，初期面临着市场不确定、资源有限的挑战。这个阶段我们更偏向于精益创业的“小而精”团队，有点像明星模式的变体——团队成员都具备多方面能力，能够快速地尝试和验证产品方向。决策速度快，每个人都承担着重要的职责。
• 项目中期（功能迭代与用户增长期）： 随着MVP的上线和用户反馈的增加，我们需要快速迭代和完善功能。这时，团队规模开始扩大，我们逐渐转向功能团队模式，并采用了Scrum敏捷开发框架。我们将整个项目拆分为多个独立的功能模块，每个模块由对应的人负责。这使得每个团队成员都能独立负责一个完整的功能交付，提高了并行开发效率。
• “转会”带来的思考： 在学期中的“转会”环节，一些成员从一个模块转到另一个模块。这让我们思考如何在团队成员变动时保持项目进度和知识传承。我们通过详细的文档、代码注释以及一些交接会议，来降低人员变动带来的影响。这也促使我们更加注重团队的知识共享和文档沉淀，而不是过度依赖某个“明星”成员的个人能力。

也就是说，没有一种团队模式是万能的。选择和调整团队模式，需要综合考虑项目所处的阶段、项目的规模和复杂度、团队成员的能力。一个成功的团队模式是能够灵活适应变化、有效分配资源、并促进成员协作的模式。

问题五：如何更有效地进行用户需求调研？

我的疑问： 如何才能更好地组合这些调研方法，提高需求获取的质量？

我的解答与理解：

学期初阅读软件工程教材时，我就意识到单一的用户调研方法存在局限性。要更有效地进行用户需求调研，关键在于综合运用多种调研方法，并根据项目的不同阶段和具体目标，灵活地确定这些方法的组合和使用顺序。

在“碎星集”App 的团队项目实践中，我们尝试了以下几种调研方法的组合，这帮助我们更全面、准确地理解用户需求：

1. 探索性调研

这个阶段的目标是了解用户的痛点、行为习惯和潜在需求，形成初步的产品设想。我们首先与少量目标用户进行了深入面谈。通过一对一的交流，我们能够更深层次地挖掘用户在内容消费与创作方面的痛点、习惯和潜在需求；此外，我们对现有内容平台进行了竞品分析。这不仅帮助我们了解市场现状、用户偏好，也识别了现有产品的不足和我们的潜在机会点，从而明确了“碎星集”App 的差异化定位。

2. 验证性调研

在有了一定的用户痛点和初步设想后，这个阶段的目的是验证产品设想和功能点是否符合用户预期，并收集具体反馈以优化设计。在这个阶段，我们设计了更具针对性的问卷。这类问卷主要用于验证特定功能点（如个性化推荐、笔记管理系统）或设计方案的用户偏好。通过收集这些数据，我们可以更科学地支撑我们的产品决策，了解哪些功能是用户普遍需要的。

当我们有了简单的MVP（特别是“我的星球”笔记模块）后，我们会邀请真实用户进行可用性测试。我们观察用户如何操作产品，例如他们如何创建笔记、如何使用富文本编辑器、如何管理内容。通过观察和用户的直接反馈，我们发现了许多设计细节上的可用性问题，并据此进行了优化。

3. 持续反馈与迭代

产品上线后，需求调研的工作并没有结束，而是转变为持续收集用户反馈，并根据数据不断优化产品功能和用户体验。我们通过用户反馈渠道（如App内反馈、小红书评论）来收集用户对产品的使用感受和建议。我们定期回顾这些反馈，并结合产品数据（如功能使用率）来评估哪些功能需要改进，哪些新功能可以考虑添加。

用户需求调研是一个持续且迭代的过程。没有放之四海而皆准的“最佳方法”，而是需要根据项目的具体阶段、目标用户群体特征以及想要解决的问题，灵活组合运用定性（如深入面谈、焦点小组）和定量（如问卷调查、数据分析）方法。同时，结合原型验证，能够帮助团队不断逼近真实的用户需求，最终开发出更符合用户期望的产品。

软件工程各阶段的知识点与“做中学”

这学期最深刻的体会就是“做中学”的重要性。理论知识在书本上是抽象的，但通过个人博客、结对编程和团队项目的实践，我才真正理解了它们的含义和价值。

以下是在项目不同阶段学到的一些核心知识点：

• 需求阶段：用户故事

  • 知识点： 用户故事是一种轻量级的需求表达方式，以用户的角度描述他们想要实现的功能及其带来的价值。
  • 我的理解： 以前觉得需求文档就是罗列功能点。但在团队项目中，我们大量使用了用户故事。例如，“作为一名学生，我希望能在App上实时查看一些美文来陶冶情操。” 这种形式让我们在设计和开发时能始终聚焦用户价值，避免了过度开发不必要的功能。它也是团队沟通的桥梁，让产品经理、开发人员和测试人员对需求有共同的理解。

• 设计阶段：模块化与高内聚低耦合

  • 知识点： 模块化设计是将系统划分为独立的、可重用的模块，高内聚指模块内部功能紧密相关，低耦合指模块之间依赖性低。
  • 我的理解： 在结对编程和团队项目中，我们都经历了系统功能不断增加、代码量爆炸的阶段。初期代码随意堆砌，后期修改一个功能常常牵一发而动全身。通过实践，我们深刻体会到模块化设计的重要性。在设计阶段，我们会尝试将系统拆分为独立的微服务或逻辑模块，并思考它们之间的依赖关系。这让代码结构更清晰，维护和扩展也变得更容易。

• 实现阶段：单元测试

  • 知识点： 单元测试是对软件中最小可测试单元进行验证，以确保其行为符合预期。
  • 我的理解： 以前觉得写单元测试很浪费时间，不如直接写业务逻辑。但在团队项目中，我们坚持编写单元测试。每次修改代码后运行单元测试，可以及时发现引入的Bug，避免了Bug堆积到后期。它还迫使我们在编写代码时思考模块的独立性和可测试性，从而写出更健壮的代码。

• 测试阶段：自动化测试

  • 知识点： 自动化测试使用自动化工具执行测试用例，提高测试效率和重复性。
  • 我的理解： 在人工测试中，回归测试非常耗时且容易出错。在团队项目中，我们逐步引入了接口自动化测试和部分自动化测试。虽然初期投入较大，但后期每次版本发布都能快速进行回归测试，大大缩短了测试周期，提升了测试质量。我意识到，自动化测试是提升测试效率、保证产品质量不可或缺的一环。

• 发布阶段：持续集成/持续部署（CI/CD）

  • 知识点： CI/CD 是一种通过自动化方式频繁集成、测试和部署代码的实践。
  • 我的理解： 在团队项目中，我们搭建了简单的CI/CD流程。每次代码提交后，会自动触发构建、单元测试和接口测试。测试通过后，可以自动部署到测试环境。这大大加快了我们的发布节奏，减少了手动操作的错误，也让我们能更频繁地将新功能交付给用户进行测试和反馈。

• 维护阶段：日志与监控

  • 知识点： 通过记录系统运行时的日志和实时监控系统指标，以便发现、诊断和解决问题。
  • 我的理解： 在项目上线后，用户反馈了一些问题。如果没有完善的日志系统，定位问题会非常困难。我们开始重视日志的规范记录（如错误日志、操作日志），并搭建了简单的监控系统（如服务器CPU、内存使用情况）。这使得我们能够及时发现系统异常，并根据日志快速定位问题根源，从而高效地进行维护和修复。

个人理解与心得体会

一个学期的软件工程学习和实践，对我而言不仅仅是掌握了一些“知识点”，更重要的是改变了我对软件开发的认知。

1. 从“写代码”到“做产品”： 以前我只关注如何写出功能代码，但现在我更关注如何“做产品”——从理解用户需求、设计解决方案、到高质量地实现、测试和发布，再到后期的维护。我理解到，软件工程是一个端到端的完整生命周期，每个阶段都环环相扣，缺一不可。

2. 团队协作的重要性： 无论是结对编程还是团队项目，都让我深刻体会到团队协作是项目成功的基石。有效的沟通、清晰的分工、互相支持和信任，远比单个成员的技术能力更重要。在团队项目中，我们共同面对困难，共同庆祝成功，这种体验非常宝贵。

3. 适应变化，拥抱不确定性： 软件开发往往充满不确定性，需求变化、技术难题、成员变动都是常态。这学期的实践让我明白，敏捷开发的核心就是拥抱变化。我们不需要追求“完美计划”，而是要学会快速响应、小步快跑、持续交付价值。

4. 实践是最好的老师： 书本上的知识固然重要，但只有通过亲身实践，才能真正将知识内化为自己的能力。从敲下第一行代码，到解决一个又一个Bug，再到最终交付产品，所有的挑战和成就都让我对软件工程有了更深刻、更全面的理解。

是否原来问题还不明白？

总体而言，我原来的问题在实践中都得到了不同程度的解答。对于燃尽图的波动、SRP和OCP的应用以及开发与测试的矛盾，我感觉有了比较清晰的认识和解决思路。

然而，对于“团队模式如何适配不同类型的项目”这个问题，我虽然理解了需要动态调整，但实际操作中依然存在挑战。例如，在项目规模进一步扩大，团队成员达到几十甚至上百人时，如何有效地从功能团队模式向更复杂的组织结构（如部落、公会）演进，并保持高效率和良好的沟通，这对我来说依然是一个需要进一步探索和学习的领域。我感觉这涉及到更深层次的组织管理和文化建设，不是简单的模式选择就能解决的。

是否产生了新的问题？

随着实践的深入，我也产生了以下问题：面对快速变化的AI技术浪潮，软件工程的开发流程和方法论需要做出哪些根本性的调整？ AI技术正在深刻改变软件开发，例如代码生成、测试辅助、甚至需求分析。未来的软件工程，是否会出现全新的范式来适应这种变革？

最后也是非常感谢老师提供的这次回顾机会，让我能系统性地梳理这学期的所学所得。我相信这些思考和实践经验将对我未来的学习和职业发展产生深远的影响。