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

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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	提升前后端开发能力，掌握软件工程方法，强化团队协作和项目管理能力，实现高效的软件开发实践。
这个作业在哪个具体方面帮助我实现目标	理解软件工程核心概念，培养批判性思维，提高对需求分析、软件设计、测试及团队协作的理解

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

🔗 回顾：起点与问题链接

在课程初期的[I.1] 个人作业：阅读和提问) 中，我提出了如下五个问题：

1. PSP（Personal Software Process）是否适用所有的团队？这与软件工程要求的敏捷开发是否有一定的冲突？
2. 单元测试是否只能由代码作者来写？这样做的利弊是什么？
3. 结对编程中“随时的复审和交流”是否真的能保证质量？
4. Scrum 强调的 self-managing（自我管理）、self-organizing（自组织）、cross-functional（跨职能） 团队理念是否过于理想？
5. 团队中PM，Dev，QA职责是否应该模糊化？

---

🧠 解答与反思：问题的回顾与新认识

✅ 问题 1：PSP（Personal Software Process）是否适用所有的团队？这与软件工程要求的敏捷开发是否有一定的冲突？

解答：PSP（Personal Software Process）和敏捷开发在理念和实践上存在显著差异，其适用性和潜在冲突需要根据团队和项目的具体情境来分析：

• 适合PSP的团队：成熟度高、需求稳定、个人能力差异大的团队。
• 适合纯敏捷的团队：需求多变、创新性强、协作紧密的团队。
• 混合模式：在敏捷框架内局部应用PSP（如关键开发者），平衡灵活性与质量。

在我的团队中，最终采用了混合模式。

---

✅ 问题 2：单元测试是否只能由代码作者来写？这样做的利弊是什么？

解答：单元测试并不一定只能由代码作者编写，但通常由作者完成更高效。是否由作者编写需权衡质量、效率、知识共享等多方面因素：

• 简单/稳定代码：作者编写更高效。
• 复杂/关键代码：他人参与提升覆盖率。
• 长期项目：通过轮岗或集体代码所有权（如敏捷团队的“Shared Testing”文化）避免知识孤岛。

最终目标是通过测试保障质量，而非拘泥于由谁编写。团队应根据项目阶段、人员能力动态调整策略。在我的团队中，大部分情况都是由代码作者编写。

---

✅ 问题 3：结对编程中“随时的复审和交流”是否真的能保证质量？

解答：结对编程（Pair Programming）中“随时的复审和交流”确实能在一定程度上提升代码质量，但其效果取决于具体实践方式、团队成熟度和上下文环境：

• 不要100%结对：针对关键代码（20%核心逻辑）投入80%的结对资源。
• 量化效果：跟踪结对后代码的缺陷率、返工率和维护成本，避免盲目实施。

结对编程的复审价值真实存在，但如同任何敏捷实践，其成功取决于人的执行而非理论本身。在我的团队中，最终没有随时，而是适时的复审和交流。

---

✅ 问题 4：Scrum 强调的 self-managing（自我管理）、self-organizing（自组织）、cross-functional（跨职能） 团队理念是否过于理想？

解答：Scrum 所倡导的 self-managing（自我管理）、self-organizing（自组织）、cross-functional（跨职能） 团队理念确实是一种理想化的目标，但并非不切实际。它的可行性取决于 团队成熟度、组织环境和文化支持。我的感受是接受“不完美”，聚焦持续改进，而非苛求理论完美。

---

✅ 问题 5：团队中PM，Dev，QA职责是否应该模糊化？

在我的团队中，成员的职责非常清晰化，拒绝了模糊化，这样有利于问题责任的追踪，提高开发效率。

---

🛠 知识点总结：六大阶段收获

阶段	所学知识点
需求	用户画像和用户故事有助于明确边界与功能优先级
设计	采用模块化设计，通过接口抽象降低耦合度，为未来功能的扩展预留了技术空间
实现	通过Linter工具和代码格式化工具统一代码风格，结合静态分析检测潜在缺陷），提升代码可读性与可维护性
测试	理解单元测试（占比70%）、集成测试（20%）、UI测试（10%）的投入比例，避免过度依赖耗时且脆弱的端到端测试。
发布	使用 GitHub Actions 实现自动化部署流程
维护	bug 复现日志 + 标签分类机制有效提升了问题追踪效率

---

💡 总结与心得

1. 个人项目：理论到实践的跨越

通过自主学习，掌握了软件工程的核心概念（如结对编程、CI/CD、竞品分析），并借助案例分析深入理解技术落地的逻辑。例如：

• 在竞品分析中，不仅对比功能差异，更关注架构设计背后的 trade-off（如性能 vs 可维护性）。
• 通过编写自动化测试脚本，体会到质量内建（Quality Built-in）的价值——缺陷预防比事后修复更高效。

2. 结对编程：协作与质量的平衡

在结对编程实践中发现：

• 即时沟通能减少认知偏差（如对需求理解的差异），但也需避免过度讨论导致的效率下降。
• 角色轮换（Driver/Navigator）让双方从不同视角审视代码，显著提升可读性与健壮性。
• 测试驱动开发（TDD）与结对结合时，能更早暴露边界条件问题，降低返工成本。

3. 团队项目：敏捷协作的真实挑战

首次深度参与团队开发后，对理论有了更立体的认知：

• 项目管理：Scrum 的站会（Daily Standup）和看板（Kanban）虽简单，但能有效暴露瓶颈（如某任务因环境依赖卡阻）。
• 角色边界：实践中发现，PM-Dev-QA 职责的适度模糊（如开发参与测试用例设计）可加速交付，但需明确最终责任人（如 QA 仍主导质量门禁）。
• 工具链整合：CI/CD 流水线的搭建，让“快速迭代”从口号变为现实（如自动化部署节省 60% 发布时间）。

总结：软件工程没有银弹，但每一次实践都在缩短理论与现实的差距。这种“发现问题-验证方案-产生新问题”的循环，正是技术人成长的本质路径。