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

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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.3] 个人作业：结课总结
我在这个课程的目标是	系统学习软件工程与软件开发相关流程和技术，完成一个完整的软件开发流程
这个作业在哪个具体方面帮助我实现目标	总结反思个人项目、结对编程和团队项目中的收获与心得

随着学期开始时的快速阅读与提问，以及随后一个学期的结对项目、两阶段团队项目和转会环节，我深刻体会到“实践是认识的来源、目的、动力以及检验认识真理性的唯一标准”。下面，我将回顾当初提出的五个问题，尝试给出解答或反思，并分享在需求/设计/实现/测试/发布/维护六个阶段各学到的一点“知识点”，最后结合个人项目、结对编程和团队项目谈谈心得。

一、以前提问题的博客

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

二、对曾提问题的解答与反思

问题一：软件发布的“足够好”标准如何量化？

解答：

• 简化框架： 在147项“发布就绪度”指标中，可先抽取「关键缺陷率」「主要功能通过率」「性能基准达标率」「用户验收反馈率」四项作为核心度量。
• 阶段性度量： 每次内部迭代发布，都对这四项做快速评估——当关键缺陷率 <1%，主要功能通过率 ≥95%，性能指标满足 SLA，且至少 80% 的内测用户反馈“可用”，即可认为“足够好”向外部灰度发布。
• 实践来源： 在项目中，我们把上述度量写入每次迭代结项标准，通过 CI/CD Pipeline 自动生成报告并在每日站会上讨论。

仍不明？ 对于“用户验收反馈率”的量化方式还在探索：如何快速得到有代表性的使用反馈？

问题二：单元测试和效能测试的优先级是否绝对？

解答：

• 风险驱动优先级： 核心业务逻辑模块优先做单元测试；若系统在高并发/大数据场景下运行，需并行开展效能测试。
• 迭代平衡： 在项目中，我们在每个 Sprint 前期完成核心模块的单元测试，后期并行压测脚本，最终以“覆盖率 ≥80% 且响应时间 ≤200ms”为验收门槛。
• 实践启示： 在某一阶段，我们曾把压测排在最后，结果上线次日出现性能瓶颈，教训在于“优先级非绝对，取决于业务和环境需求”。

问题三：敏捷开发是否适用于强合规性领域？

解答：

• 混合流程： 在医疗/金融项目中可采用“敏捷＋阶段性审计”模式，Sprint 内完成迭代，同时在每两—三 Sprint 后并行进行文档审计和回溯测试，保证合规。
• 实践方法： 我们在项目里定义了“合规 Sprint”：专门产出 Traceability Matrix 和审计报告，并将其纳入 Definition of Done。
• 作者低估？ 教材只讲了敏捷的快速响应优势，忽略了合规领域对文档和过程的重度依赖。

问题四：单元测试的“100% 覆盖率”是否必要？

解答：

• 价值导向覆盖： 质量保障教我们覆盖核心路径，非核心或自动生成代码可适当放弃。
• 实践案例： 我们对支付流程、权限校验等关键路径追求高覆盖，对界面样板代码只做抽样测试。最终发现，故障主要出在边缘逻辑，而非覆盖率低的模块。
• 结论： 100% 覆盖率带来高成本且收益递减，不必盲目追求。

问题五：项目经理(PM)是否应具备基本技术能力？

解答：

• 混合角色模型： PM 不必成为深度开发者，但应掌握常见架构、技术栈和术语，才能高效沟通、评估风险与进度。
• 团队实践： 我们的 PM 对关键接口设计示意图能“秒懂”，在评审时能及时指出潜在技术风险，项目进度大大提升。
• 反思： 非技术 PM 容易错过细节，延后沟通成本反而更高。

三、产生的新问题

1. 技术债务在敏捷框架下如何持续管理？
2. 如何在短迭代中兼顾安全和合规的持续验证？

四、六个阶段各学到的一个“知识点”

阶段	学到的知识点
需求	利益相关者访谈：通过用户角色画像提炼隐性需求。
设计	UML/时序图建模：用可视化方式验证模块间交互是否合理。
实现	代码规范与评审：制定 ESLint/Prettier 规则并严格执行。
测试	测试驱动开发（TDD）：先写测试再写实现，提高设计质量。
发布	CI/CD 自动化：通过 GitHub Actions 一键构建与部署。
维护	持续重构：通过静态分析与技术债务仪表盘跟踪重构需求。

五、结合个人/结对/团队项目的理解与心得

• 个人项目：在“软件案例分析”中，通过对典型软件系统架构与设计模式的深入剖析，学会了如何根据场景选型、评估优劣，并撰写完整的案例报告，提升了需求理解与设计评审能力。
• 结对编程：与伙伴互相交叉 code review，发现自己常犯的命名与注释习惯问题，也学会了“说出自己的思路”才能让对方高效帮助。
• 团队项目：六人协作时，沟通节奏和工具链（Git Flow、看板、Slack）至关重要；定期同步、快速原型与持续集成让我们在两阶段里按时交付。

通过本次提问回顾与总结，我深感“做中学”的价值：每一个问题的答案，都来自于书本与实践的结合；每一个阶段的收获，都源于团队协作与自我驱动。未来，我将继续在项目中应用这些方法，不断迭代和优化，也期待在新的问题里获得更多真知。