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

项目	内容
这个作业属于哪个课程	2025年春季软件工程（罗杰、任健
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习系统化软件工程知识，增进个人专业化素养，打造令人满意的软件产品
这个作业在哪个具体方面帮助我实现目标	通过软件开发的全生命周期的深入阅读和学习，以极短的时间领略软件开发所需的专业知识

问题一

在敏捷开发中，如何平衡技术债务与快速交付的需求？
在实际项目中，技术债务的积累往往是一个隐性问题，团队为了满足短期的交付目标，可能会选择牺牲代码质量或跳过必要的设计评审，例如，在一次紧急功能开发中，团队为了赶进度，直接复制了现有代码并进行了简单修改，导致代码库中出现了大量重复逻辑，虽然短期内功能按时交付，但后续的维护和扩展变得异常困难，甚至需要花费数倍的时间来修复这些问题，书中提到的“持续集成”和“重构”确实是减少技术债务的有效手段，但在实际执行中，团队常常面临时间压力和资源限制，例如，重构需要额外的时间和测试覆盖，而在紧张的迭代周期中，这些工作往往被优先级更高的功能开发所挤占，因此，或许需要在敏捷开发中引入更明确的技术债务管理策略？例如，为每个迭代预留一定比例的时间用于技术债务清理，或者通过技术债务的量化评估（如代码复杂度、重复率等）来帮助团队更好地权衡短期交付和长期维护的需求。

问题二

在分布式团队中，如何有效实施代码审查？
在分布式团队中，代码审查的效率和质量往往受到时区差异、沟通障碍和文化差异的影响。例如，某团队的核心开发人员位于亚洲，而代码审查的主要负责人位于北美，双方的工作时间几乎没有重叠，这导致代码审查的反馈延迟，进而影响开发进度，此外，由于缺乏面对面的沟通，审查意见可能会被误解，甚至引发不必要的争论，而书中提到的“代码规范”和“工具支持”确实是代码审查的基础，但在分布式团队中，这些措施可能不足以解决问题，例如，是否可以通过引入异步代码审查平台（如GitHub的Pull Request功能或Gerrit）来优化审查流程？这些工具允许开发人员在合适的时间进行审查，并通过清晰的评论和讨论记录来减少沟通障碍，此外，是否可以通过制定更详细的审查指南（如明确审查的重点和优先级）来帮助分布式团队更高效地完成审查任务？

问题三

如何解决强制分配绩效等级带来的困境？
讲义中提到强制分配绩效等级（如10%的最差成员）在优秀团队中可能导致不公平，但未提供解决方案，例如，优秀团队的经理被迫将表现不错的成员归为最差的10%，文中提到强制分配绩效等级的弊端，但未讨论如何调整评估体系，例如，某优秀团队因强制分配最低绩效等级导致士气下降，这是否意味着需要调整绩效评估体系，避免对优秀团队强制分配最低绩效等级？另一方面而言，文中亦提到“背靠背评比”可能导致小团体抱团和劣币驱逐良币，并介绍了Valve公司的队友评估机制，但未详细说明如何避免这些问题，例如，Valve公司通过队友评估机制，从技术能力、劳动生产力、团队贡献和产品贡献四个维度评估绩效，但未讨论如何确保评估的公平性，例如，某团队中由于小团体抱团，导致优秀成员的绩效被低估，这是否意味着需要引入更透明的评估机制或工具来减少人为干扰？

问题四

在微服务架构中，如何设计有效的故障隔离机制？
书中第八章提到微服务架构的优势，但未详细讨论如何设计故障隔离机制以避免单点故障影响整个系统。例如，某电商平台的支付服务因故障导致整个系统不可用，暴露了故障隔离机制的不足，书中提到“服务拆分”和“独立部署”是微服务的特点，但未深入探讨如何通过设计模式（如熔断器、限流器）实现故障隔离，这是否意味着需要在微服务架构中引入更复杂的容错机制？或者应当从需求端的角度便对电商服务的技术规范实行要求？

问题五

如何评估软件工程中的技术选型风险？
技术选型是软件工程中的关键决策之一，但其风险往往被低估。例如，某团队选择了一款新兴的NoSQL数据库技术，初期因其高性能和灵活性而备受青睐。然而，随着项目的推进，团队发现该技术的社区支持不足，文档匮乏，且缺乏成熟的运维工具，导致后期维护成本大幅增加，书中提到的“技术栈”和“工具链”确实是项目成功的关键，但在实际选型中，团队往往缺乏系统化的风险评估方法。例如，是否可以通过建立一个技术选型的风险评估框架来帮助团队更好地权衡各种因素？该框架可以包括以下几个维度：
技术成熟度：该技术是否经过大规模生产环境的验证？
社区支持：是否有活跃的社区和丰富的学习资源？
长期维护成本：该技术的更新频率和向后兼容性如何？
团队熟悉度：团队是否具备使用该技术的经验和能力？
软件生态：是否有成熟的工具链和第三方支持？
通过系统化的评估，团队可以更全面地了解技术选型的风险，从而做出更明智的决策。