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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健）
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	运用软件工程原理与敏捷开发方法，通过全生命周期工程化管理，打造卓越软件产品
这个作业在哪个具体方面帮助我实现目标	通过精准定义需求边界，系统化解构设计矛盾，深化对软件全生命周期中需求工程与质量保障体系的工程化实践认知

1.敏捷开发中的用户故事与传统需求文档如何平衡？
书中第三章提到敏捷开发中的用户故事是一种轻量级的需求表达方式，强调与用户的直接沟通和快速迭代。然而，在实际工作中，尤其是在一些传统行业或大型企业中，正式的需求文档仍然是必不可少的，比如为了满足合规性要求或作为合同交付物。这让我产生了一个疑问：如何在敏捷开发中既保持用户故事的灵活性，又能生成符合传统规范的需求文档？例如，我在参与一个银行系统升级项目时，团队采用了敏捷开发，但最终交付时，客户要求提供详细的需求规格说明书，导致我们不得不花费大量时间将用户故事“翻译”成正式文档。这是否意味着敏捷开发在某些场景下并不完全适用？还是说我们忽略了某种更好的实践方法？

2.技术债的量化与优先级评估是怎么样的呢？
第五章提到技术债是软件开发中不可避免的问题，但书中更多的是从概念上讨论其影响，而没有给出具体的量化方法。这让我感到困惑，因为在项目管理中，技术债的优先级往往需要与其他功能开发需求竞争资源。例如，在一次项目复盘会上，开发团队提出需要两周时间偿还技术债，但产品经理认为新功能的开发更为紧迫。最终，技术债被推迟，结果在下个版本中导致了严重的性能问题。那么，有没有一种系统的方法可以量化技术债的成本和风险，从而帮助团队更好地决策？这个问题源于我对书中内容的延伸思考，也反映了实际项目管理中的痛点。

3.微服务架构下的性能测试挑战有哪些？
第七章详细介绍了微服务架构的优势，比如模块化、独立部署和扩展性，但书中并没有深入讨论在这种架构下如何进行有效的性能测试。微服务的分布式特性使得性能测试变得复杂，例如，服务之间的网络延迟、数据一致性以及服务链路的调用深度都可能成为性能瓶颈。在一次实际项目中，我们的微服务系统在单体测试时表现良好，但在全链路压测中却出现了严重的性能问题，最终发现是由于某个服务的数据库连接池配置不当导致的。这让我思考：在微服务架构下，是否有系统化的性能测试方法论？如何设计更贴近真实场景的测试用例？这个问题源于我的实际经验与书中内容的差距。

4.DevOps实践中自动化与安全性的平衡要怎么做？
第九章讨论了DevOps的核心实践，强调通过自动化实现快速交付，但书中对安全性的讨论相对较少。在实际项目中，自动化流水线的引入确实提高了效率，但也带来了新的安全隐患。例如，在一次部署中，由于自动化脚本的权限配置不当，导致生产环境的部分敏感数据被意外暴露。这让我产生疑问：在DevOps实践中，如何在追求自动化的同时，确保安全性不被忽视？是否有成熟的最佳实践或工具可以帮助团队更好地平衡这两者？这个问题源于我对书中内容完整性的质疑，也反映了实际项目中的痛点。

5.AI辅助编程工具对代码审查流程的影响如何？
第四章详细介绍了代码审查的重要性，但书中并未提及AI辅助编程工具（如GitHub Copilot）对代码审查流程的潜在影响。随着这类工具的普及，开发者的编码效率得到了显著提升，但也带来了新的挑战。例如，在一次代码审查中，我们发现某段由AI生成的代码虽然功能正确，但可读性较差，且缺乏必要的注释。这让我思考：在AI工具的辅助下，代码审查的重点是否需要从传统的“发现错误”转向“确保代码可维护性和一致性”？这个问题源于新技术发展对书中内容的补充需求。

6.如何评估架构决策的长期成本？
第七章讨论了软件架构设计的基本原则，但书中对架构决策的长期成本评估涉及较少。在实际项目中，架构决策往往需要在短期收益和长期维护成本之间权衡。例如，在一次系统重构中，团队选择了一个看似高效的架构方案，但后来发现该方案对运维团队的技术要求极高，导致长期维护成本远超预期。这让我思考：是否有系统化的方法可以帮助团队在架构设计阶段评估其长期成本？这个问题源于我对书中内容实用性的延伸思考。