智能软件工程 课件 Ch8-下一个版本如何开始

智能软件工程第8章下一个版本如何开始？软件交付之后？软件交付或发布标志着阶段性任务的完成，但开发者仍需持续参与运维环节。运维阶段，团队根据系统监测和用户反馈，希望修复和改进软件，并发布更新版本。下一个版本的开发流程与第一个版本无本质不同，DevOps环状结构显示运维监测后是“计划”阶段。大多数开发属于“增量开发”，即在原有代码基础上实施改进，而非从零开始。软件维护软件维护是软件交付或发布之后，开发团队对软件进行修正、改进和优化的常规开发活动。软件维护的目的是确保软件能够持续满足用户需求、适应环境变化，并保持高效运行。软件维护是一个持续的过程，从软件第一个版本交付开始，直到整个生命周期结束。在软件的整个生命周期中，软件维护占据重要的部分，成本占比高达67%，远高于其他活动（如代码实现或测试）。不同软件开发活动的成本8.1软件维护8.2软件演化8.3向智能化软件演进8.1

软件维护软件维护类型：纠错性维护(Corrective)目标：修复软件中的错误或缺陷，确保软件在预期条件下正常运行。错误来源：用户报告（最常见）、自动化测试、系统监控和日志分析等。错误分级与处理：严重错误（如系统崩溃）需立即修复；一般错误需及时处理；轻微错误（如界面小问题）可安排在后续版本。修复流程：分析报告、重现问题、找到根源、实施修复，并通过严格测试验证。软件维护类型：适应性维护(Adaptive)使软件能够适应外部环境的变化，确保在新环境下稳定、高效运行。环境变化类型：操作系统升级：可能导致原有软件兼容性问题，如API被弃用。硬件更换：需要对软件进行优化和调整，如更新驱动程序。外部接口变动：如数据库、网络服务或第三方API规范变更。法规和标准的变化：如数据隐私保护法规更新要求软件增加相应功能。软件维护类型：完善性维护(Perfective)对软件进行改进和增强，提升其功能、性能和用户体验。主要活动：增加新功能或改进现有功能，以满足用户需求和市场竞争。改善用户界面，提高易用性和可操作性。提升软件性能，例如优化数据库查询和缓存机制。增强安全性，如增加多因素认证机制或改进数据加密。软件维护类型：预防性维护(Preventive)通过主动措施预防潜在问题，提升软件的稳定性、可维护性和使用寿命。具有前瞻性，旨在问题发生之前采取行动，减少未来维护成本。主要活动：代码重构：优化代码结构，提高可读性、可维护性和扩展性，但不改变软件的外部行为。定期检查并更新软件的依赖项与技术栈，以获取最新功能和安全修复。数据备份和恢复机制，应对数据丢失和系统故障风险。可维护性指标软件的可维护性(maintainability)可以通过指标（metrics）进行量化评估。一些关键量化指标包括：圈复杂度(CyclomaticComplexity)和代码行数(LoC)在一定程度上反映了可维护性（数值越高，维护难度可能越大）。可维护性指标(MaintainabilityIndex,MI)：综合考虑Halstead复杂度（V）、圈复杂度（G）、代码行数（L）以及代码注释的比例（C）。根据MI公式，复杂度越小、代码量越少、注释比例越高的软件，可维护性指标越高。可维护性指标

角度指标可测试性代码覆盖率、功能覆盖率、缺陷检测率、测试执行时间等结构简单性圈复杂度、耦合度、内聚度、代码重复率等可理解性注释密度、代码长度等度量软件可维护性的不同角度与指标软件腐化(Software/CodeDecay)定义：随着时间的推移，软件系统的质量和可维护性逐渐下降的现象。可能原因：软件长期经历频繁的缺陷修复和功能添加，且这些改动未经充分的考虑。软件原有的设计无法适应新的需求和技术变化，导致维护成本增加。开发团队成员的频繁变动，导致知识流失和代码一致性下降。软件技术债(Technicaldebt)的累积，是导致腐化的主要因素之一。软件技术债(TechnicalDebt)定义：开发者为了快速交付而采取的临时、低质量的解决方案，如由于时间压力采取的“紧急修复”或“权宜之计”(workaround)。成本：未来对这些低质量代码进行重构或维护而付出的成本，被形象地比喻为欠下的技术债的“利息”。来源：技术债不仅源于紧急修复，也可能源于企业在特定时间点合理的、但长期来看是次优的商业决策。软件技术债：StackOverflow案例2016年，一位Web开发者参与了StackOverflowTalent（前StackOverflowCareers）登录界面的重设计工作。目标是将旧界面修改为新界面，以简化登录流程并提高用户体验。原界面新界面软件技术债：StackOverflow案例2016年，一位Web开发者参与了StackOverflowTalent（前StackOverflowCareers）登录界面的重设计工作。目标是将旧界面修改为新界面，以简化登录流程并提高用户体验。原界面新界面/case-study-stack-overflow软件技术债：StackOverflow案例看似简单的工作，实际面临的挑战：代码库分离：原系统负责登录和注册的代码分属于两个不同的代码库。数据存储分散：用户的邮箱信息存储在两个不同的数据库里。功能受限：数据分散等设计导致用户无法使用新邮箱来重置密码。此外，用户在登录后无法更改密码，必须通过“忘记密码”功能重置。技术与维护难度：开发者必须处理陈旧的登录页面和复杂的后台系统。过时的技术和框架使得系统的维护和更新变得困难。软件技术债：StackOverflow案例看似简单的工作，实际面临的挑战：代码库分离：原系统负责登录和注册的代码分属于两个不同的代码库。数据存储分散：用户的邮箱信息存储在两个不同的数据库里。功能受限：数据分散等设计导致用户无法使用新邮箱来重置密码。此外，用户在登录后无法更改密码，必须通过“忘记密码”功能重置。维护难度：必须更新过时的依赖项，以使其在本地开发环境中运行软件技术债：StackOverflow案例StackOverflow的技术债并非一朝一夕形成，而是多年间不同的商业决策逐渐累积的结果。2008年：OpenID采用StackOverflow主站上线，最初采用OpenID作为用户身份验证方式。随着时间推移，OpenID的局限性显现，大多数网站转向更简单的协议。2009年：CareersAuth引入推出独立的StackOverflowCareers网站。为了简化雇主的登录流程，团队开发了内部的CareersAuth(OpenIDprovider)。CareersAuth应用和数据库与主应用分离，导致系统复杂且维护困难。2011年：双重实现StackOverflowQ&A主站开始支持用户名/密码登录。为了避免破坏Careers的登录功能，主站采取了全新的OpenIDprovider实现。公司需要维护两个独立的OpenIDproviders，进一步增加了系统的维护复杂性和技术债成本。软件腐化的监控指标腐化是一个随时间推移而出现的缓慢过程，监控指标通常包含时间因素，例如：纠错性维护请求数量：数量随时间增加，可能表明系统引入错误的速度快于修复速度。实现一个变更请求的平均时间：所需时间随时间推移越来越长，表明代码改动难度增加，系统可维护性下降。变更影响分析的平均时间：所需时间越来越长，可能意味着系统的耦合度增高，一个变更可能“牵一发而动全身”。代码重构代码重构的定义重构是改进代码的过程，目的是降低软件复杂性，使程序更易于理解与维护。代码重构是减缓软件腐化、提升系统结构与质量的关键手段。核心特点：不改变代码的外部行为，只改善其内部结构(添加新功能和修改外部接口不属于重构，因为它们改变了代码的外部行为）。重构的频率与时机重构是一个贯穿系统整个生命周期的、持续的过程，不应限定于特定的时间节点。开发者应将重构当作日常开发的一部分。建议创建独立分支进行重构，避免影响其他成员的工作。代码重构的触发时机当你第三次重复做某件事情时：表明存在不必要的重复性代码。当添加新功能比预期困难许多时：可能系统存在多余依赖或隐藏假设。当调试或缺陷修复遇到困难时：代码可能太过复杂、结构混乱，降低复杂性有助于缺陷追踪。代码异味存在一些固定模式的代码，可以通过特定类型的重构加以改进。我们一般将这类代码称为“codesmell”，直译是“代码异味”，意思就是你感觉这个代码不对劲、不给力，需要改进，即“thiscodedoesn'tsmellgood”，或者“thiscodedoesn'tfeelright”。代码异味：臃肿的代码(Bloaters)过于冗长的方法、类或方法参数列表，通常是长期累积的结果。重构方法示例：提取方法/提炼函数(ExtractMethod)：将冗长代码中重复或复杂的片段提取到新的、独立的方法中，使结构更清晰。代码异味：臃肿的代码(Bloaters)过于冗长的方法、类或方法参数列表，通常是长期累积的结果。重构方法示例：以方法调用取代参数(Replaceparameterwithmethodcall)：移除冗余参数，简化方法调用。代码异味：臃肿的代码(Bloaters)过于冗长的方法、类或方法参数列表，通常是长期累积的结果。重构方法示例：以方法调用取代参数(Replaceparameterwithmethodcall)：移除冗余参数，简化方法调用。代码异味：滥用面向对象(OOAbusers)不恰当地使用或过度滥用面向对象特性（如封装、继承、多态），导致设计不良。例如，不合理的继承关系可能导致子类继承了许多不相关的属性和方法。重构方法示例：以委托取代继承(Replaceinheritancewithdelegation)：避免不合理的继承，将所需功能类作为字段，通过“委托”调用其方法，而非直接继承代码异味：“老顽固”代码(ChangePreventers)非常难以修改的代码，因为实现一个修改需要改动许多其他代码。类似“散弹枪手术”(ShotgunSurgery)，即一个逻辑判断分散出现在系统多处，修改时需要处理多处伤口。重构方法示例：将分散的判断逻辑提取成一个独立的方法（ExtractMethod），后续变更只需修改该方法。代码异味：耦合怪(Couplers)不同类或模块之间过度耦合，阻碍了代码使用的灵活性。主要类型及重构：FeatureEnvy：某一类过度“依恋”或“嫉妒”不属于自己的类成员。可能的重构包括移动方法(MoveMethod)，将过度依赖另一个类成员的方法移动到该类中，实现解耦。代码异味：耦合怪(Couplers)不同类或模块之间过度耦合，阻碍了代码使用的灵活性。主要类型及重构：FeatureEnvy：某一类过度“依恋”或“嫉妒”不属于自己的类成员。可能的重构包括移动方法(MoveMethod)，将过度依赖另一个类成员的方法移动到该类中，实现解耦。InappropriateIntimacy：两个类对彼此过于了解和依赖，甚至直接访问对方的私有字段。消息链(MessageChains)：一个对象通过一系列方法调用链来调用另一个对象的方法，违反“迪米特法则”。中间人(MiddleMan)：一个类的大多数方法只是简单地调用其他类的方法，没有实际功能，降低了系统透明度。代码异味：非必要的代码

(Dispensables)可有可无，其存在反而对代码整洁和可读性带来负面影响。主要类型：Deadcode：存在但从未被执行或调用的代码片段。LazyClass：几乎没做什么事，可能是经过多次重构和迭代后变得单薄的类。此类代码异味应该被及时移除，以简化代码智能维护和升级主动监控与非结构化数据挖掘：利用LLM/NLP实时检测用户论坛、社交媒体等非结构化数据中的热点问题和用户反馈。自动化整合改进建议，对潜在缺陷进行早期预警并提供可量化的改进报告。历史数据学习与上下文追踪：通过深度学习分析历史数据，实现知识迁移，避免重复性错误。实现自动化补丁生成（如DeltaFix）和LLM辅助的代码重构，以降低升级复杂度。解析Git提交记录、代码审查等，识别共性问题并提出改进建议。依赖关系解析与安全性能提升：LLM可对项目依赖历史进行知识建模，自动预估依赖变更可能引发的风险。自动化工具（如GitHubDependabot）扫描并修复依赖漏洞，确保版本更新的安全与性能。智能维护和升级企业实践案例GitHubCopilot：辅助代码补全、识别代码潜在问题和推荐重构策略。微软AzureDevOps：嵌入LLM智能工具，分析项目历史数据并自动检测版本升级中的风险。谷歌内部工具：在CI/CD体系中实现对依赖关系、风险评估的全流程智能化管理。发展方向：融合多模态数据（代码、文本、图表等）以提升系统整体感知能力。实现持续学习与领域适应，以应对不断演进的开发语言和框架。强调人机协同，通过AI辅助技术支持开发者决策。8.2

软件演化版权所有©️仅限于教学使用软件演化定义软件演化（SoftwareEvolution，又称“软件进化”）指软件系统在交付之后，为了满足变更的需求并持续创造价值，而不断改进的过程。软件的生命周期越长，演化过程就越长，其新版本与最初版本在设计到实现上的差异可能越大。软件演化与软件维护的关系软件演化和软件维护的概念类似，两者本质上都描述了软件交付后为适应需求和环境变化而不断适应与进化的过程。两者经常被一起提起，有时可以交换使用。区别侧重：软件维护包含纠错性、适应性、完善性、预防性四种变更。而“软件演化”概念更侧重于适应性维护（适应新环境、新需求）和完善性维护（新功能的添加）。软件演化：案例MicrosoftWord演化历史（图片来源网络）软件演化：案例NetflixDataPipeline是Netflix用于在云规模上收集、聚合、处理和传输数据的核心基础设施。V1.0版本：Chukwa管道(批处理系统)架构：主要用于聚合和上传事件到Hadoop/Hive进行批处理。流程：Chukwa收集事件，以Hadoop序列文件格式写入S3，大数据平台团队处理S3文件，最后写入Hive。性能：端到端延迟最多可达10分钟，足够满足每日或每小时扫描数据的批处理任务。V1.5版本：引入实时分支改进：在保持原有S3/EMR批处理功能的基础上，增加了实时分支。机制：将约30%的事件流分支到Kafka进行实时处理。核心：路由器负责将Kafka数据路由到Elasticsearch或二级Kafka等接收端，使用户能够进行实时流处理。V2.0版本：Keystone管道(简化架构)目标：面对V1.5复杂的操作和管理挑战，推出V2.0简化架构。架构：通过前置Kafka提高数据持久性和可操作性。Kafka负责将数据从Kafka转移到S3、Elasticsearch和二级Kafka等接收端。成果：每次演化都显著提升了系统的性能、灵活性和用户自由度，满足了Netflix不断增长的数据处理需求。遗留系统遗留系统指在企业、组织中已使用了较长时间，但仍然在运行的计算机系统、应用程序或技术。这类系统通常是在过时的软硬件或技术平台上开发的。尽管遗留系统不再适用于现代技术，但因其在日常运营中的关键作用而仍被继续使用。企业技术占比遗留系统遗留系统组成遗留硬件：已经过时但仍在使用的计算机硬件组件，如PS/2和VGA接口。遗留代码：采用了老旧编程语言、框架或技术。例如，COBOL语言在金融、银行和政府部门中仍有超过2000亿行代码在运行。遗留系统示例微软的InternetExplorer（IE），或已停止支持的WindowsXP（仍在ATM操作系统等领域使用）。MS-DOS仍在一些企业中用于运行遗留应用程序。遗留系统：风险与挑战遗留系统通常被称为“老”系统，其问题的影响往往是巨大的。运营与性能挑战功能故障：2017年美国国税局（IRS）的系统故障导致数百万电子报税无法处理。压力承载：COVID-19期间，美国多数州的失业系统（基于COBOL）无法处理大量失业请求，且缺乏COBOL程序员。维护成本高昂：遗留系统不会从原开发者处获得技术支持，需要IT团队进行持续且昂贵的维护。零售业将近58%的IT预算用于维护遗留系统。技术与安全风险安全漏洞：依赖过时的安全措施或补丁，容易受到数据泄露和安全攻击。数据孤岛：遗留系统无法与新软件、新技术集成，导致存储在其中的数据无法与其他部门共享。遗留系统：风险与挑战遗留系统：管理策略策略一：彻底弃用（abandon）。这个策略对遗留系统实施的改动程度为零，因为企业准备彻底放弃使用这个系统。策略二：常规维护（regularmaintenance）。这个策略对遗留系统实施小范围、小幅度的改动。这些改动也基本是被动而非主动的。当用户提出需求时，团队会实施相应的维护工作；否则不会主动去改进系统。可以认为，这个策略是仅实施维护系统平稳运行与满足用户需求的最小改动。策略三：替换部分系统或整个系统（replacement）。在成本允许的情况下，使用更新、更好的现有系统（硬件或软件）替换遗留系统的部分组件或者全部组件。这个策略对遗留系统本身实施的改动较大，因为要将遗留系统与被替换的部分实施整合。据IEEE报道，自2010年以来，全世界范围内至少有2.5万亿美元用于尝试替换旧的IT遗留系统，而其中约有7200亿美元被浪费在失败的替换工作上。由此可见，替换策略带来的风险也较大。策略四：现代化（modernization）。这个策略对遗留系统实施主动的、大幅度的（甚至激进的）改造，目标是改善项目的整体质量，并使其适应现代的技术、开发环境与最佳实践。现代化的手段包括代码重构、架构重构（re-architecting）、软件再工程（re-engineering）等。遗留系统：管理策略不同类型遗留系统可以使用哪些管理策略？遗留系统：现代化策略封装(Encapsulation)方式：将遗留系统的功能封装在服务接口（如API或Web服务）内部，使其能够与现代应用程序和服务进行交互。特点：不需要对遗留代码进行大规模修改，在保留核心功能的同时，为新的外部用户提供了一个访问层。示例：将基于COBOL的保险索赔功能对外暴露为RESTfulAPI。迁移(Rehost)方式：将遗留系统迁移到新的硬件或云基础设施上，利用现代硬件或云服务的性能和可扩展性优势。特点：不改变其代码或架构。示例：将在物理服务器上运行的遗留ERP系统容器化并迁移到云平台。平台切换(Replatform)方式：对遗留系统进行较少的代码修改，以适应新的平台或操作环境；在保持遗留系统核心逻辑不变的同时，利用新平台的性能和功能优势。示例：从旧版数据库迁移到最新版本（如Oracle10g迁移到PostgreSQL），或将WebLogic服务器切换到Tomcat。遗留系统：现代化策略重构(Refactoring)方式：通过修改代码内部结构，但不改变其外部行为，来提高代码的可维护性和性能。示例：将遗留系统中使用的大量重复代码提取成共享函数或类，减少冗余。重架构(Re-architecting)方式：对遗留系统的架构进行重大修改，以更好地适应现代技术和业务需求。示例：将庞大的单体电商遗留系统转换成微服务架构。替换(Replace)方式：完全用新的系统替换旧的（部分）遗留系统。过程：可能涉及重新评估业务需求、设计和开发新旧系统的“胶水”用于整合，并逐步迁移旧系统的数据和功能。重新开发(Rebuild)方式：从头开始重建整个系统，同时保留其核心业务逻辑；结合最新的开发技术和最佳实践，创建一个更高效、可维护的新系统。示例：重新开发新的贷款处理系统，利用最新的云原生技术和微服务架构。遗留系统：现代化策略不同策略的风险、收益与成本（圆形面积）遗留系统：软件再工程当上述多个改造策略被系统性、有计划地应用于某个遗留系统时，此过程被称为“软件再工程”。软件再工程的输入是一个遗留系统，输出是一个改造或进化后的系统；通常包含以下三个核心步骤：逆向工程(Reverseengineering):逆向工程旨在在缺乏文档的情况下，深入理解遗留系统的工作原理，并复原其设计与需求。系统转变(Systemtransformation):系统转变特指从旧版本到新版本在需求、设计和实现（如重构或重架构）等多个软件层次上进行的变化。正向工程(Forwardengineering):正向工程是按照一般的软件开发流程，基于系统转变后的新设计或新需求，最终开发出改造后的新系统的过程。架构重构：单体到微服务案例Twitter（现在的“X”）：最初使用单一的Ruby-on-Rails应用（“Monorail”），后在2014年选择微服务路线，将单体API服务转换为一组14个微服务。Netflix：早期采用紧密集成的单体应用，随着用户增长，架构成为可扩展性的瓶颈。2009年决定迁移到基于云的微服务架构，目前拥有超过一千个微服务。Atlassian：由于Jira和Confluence的扩展挑战，于2018年转向基于微服务的多租户、无状态云应用程序架构。挑战与风险对重架构的投入成本非常高，过程漫长，且不一定能立即带来直观收益。需要把控每一次改动的风险。例如，A对其单体架构的重架构过程持续了多年。架构重构：“绞杀者”模式业界推荐采用“循序渐进”或“增量演进”的方式进行重架构。MartinFowler将其称为“绞杀者”方式（StranglerFig）将需要改造的单体架构视为宿主植物。在单体架构的基础上，慢慢构建微服务。这些微服务可能来自新的需求（“榕树”自身的产物），也可能从单体架构中分解而来。随着时间推移，微服务越来越多，单体架构越来越小，最终单体架构被微服务架构完全取代。架构重构策略一：将新功能实现为服务目的：阻止单体架构的规模继续扩大。方式：针对新的需求（如TMS系统的智能推荐功能），新搭建一个独立的微服务。通过API网关将对新服务的请求路由到新的服务中。可以使用“胶水代码”让新服务调用单体的数据或功能。架构重构策略二：前后端分离将前端和后端分离成单独的应用并使用独立的代码库。后端将业务逻辑封装成RESTAPI，供前端远程调用。使前后端作为单独的应用可以独立开发、测试、部署。架构重构策略三：将业务逻辑提取为服务将单体应用中独立的业务逻辑拆分出来，提取为独立的服务。实施上需采用“循序渐进”或“增量演进”的方式。此策略是三种策略中最复杂的一个，通常在应用了策略一和策略二之后实施。实施上需采用循序渐进的方式。示例：将TMS系统的聊天功能提取为服务架构选择重架构的根本目标：使用适合业务场景和需求的架构，而非盲目追随“最流行”的架构（例如，微服务架构）。并非所有应用都适合微服务：尽管微服务架构是热门趋势，但这不意味着所有单体应用都适合转换。“没有一种架构模式可以适用于所有场景”：当系统规模增长一个数量级时，应重新审视现有架构，判断其是否仍能支持下一个数量级的增长。架构选择弃用“弃用”（Deprecation）指的是将某个系统、组件、API或代码标记为过时且不再推荐使用，并在此过程中逐步由其替代方案取代的过程。弃用本质上是对系统实施变更。何时需要弃用？老旧不等于弃用：系统的“老旧”（存在时间长）并不代表它一定要被弃用。如果老旧系统仍能稳定运行，且性能满足当前业务需求，没有明显瓶颈，可以继续使用。如果没有明显优于老旧系统的替代品，该系统也无需弃用。弃用案例研究：“老旧”系统一定需要被弃用吗？LaTeX是一种广泛使用的排版系统，早在20世纪80年代就已经发布了。尽管Latex是一个“老”系统，但它高质量的排版能力、稳定性和成熟性，使其在处理复杂文档排版、数学公式和参考文献时具有无可比拟的优势。这些特点使LaTeX成为撰写学术论文、书籍和技术文档的标准工具，在学术界和出版业中有着重要地位。LaTeX的优势不仅体现在其卓越的排版能力上，还包括其广泛应用的生态系统和可扩展性。经过几十年的发展，LaTeX已经非常稳定和成熟，并拥有庞大的用户社区和丰富的文档资源。同时，LaTeX还具备大量的宏包，这些包大大扩展了其功能，使用户能够根据需求定制文档格式和功能。这种灵活性和可扩展性进一步巩固了LaTeX在专业排版领域的地位。LaTeX的学习曲线较陡，初学者可能会觉得难以入门。因此，从用户体验和易用性的角度来说，现代化的所见即所得的编辑器（比如Markdown）可能更具优势。不过，在需要高质量排版、复杂公式和严格文档格式的场景中，Latex仍然是最佳的选择，弃用的可能性不大。弃用“弃用”（Deprecation）指的是将某个系统、组件、API或代码标记为过时且不再推荐使用，并在此过程中逐步由其替代方案取代的过程。弃用本质上是对系统实施变更。何时需要弃用？老旧不等于弃用：系统的“老旧”（存在时间长）并不代表它一定要被弃用。如果老旧系统仍能稳定运行，且性能满足当前业务需求，没有明显瓶颈，可以继续使用。如果没有明显优于老旧系统的替代品，该系统也无需弃用。弃用：挑战过时的系统通常已经被使用了很长时间，积累了许多显式的和隐式的依赖。Hyrum'sLaw：系统的用户越多，用户以意外和不可预见的方式使用它的概率就越高。在这种情况下，“一刀切”地移除旧系统是不可行的，会为系统运行带来极大的风险。用新系统替换旧系统面临的挑战是，新旧系统在功能、接口等方面并非严格一一对应。弃用常见策略：依赖发现目标：在弃用API之前，充分了解其所有依赖关系，做好影响分析。静态分析：通过工具扫描代码库，确定哪些方法在直接或间接调用被弃用的API。优势是无需实际运行程序，可以快速、全面地分析大型代码库。日志记录（Logging）：通过在API中添加日志记录，监控运行时实际调用该API的代码部分。优势是可以捕捉到动态调用情况，尤其是那些在静态分析中难以发现的依赖关系。弃用常见策略：预警标志对受API弃用潜在影响的用户提供提示。当开发者试图调用这些被标记的API时，IDE和编译器会发出警告。可以在代码编写和审查的早期阶段自动检测对弃用API的使用，减少人为错误。弃用常见策略：日落期（Sunsetting）日落期通常分为两个阶段：完全功能支持阶段：API仍完全可用，开发团队继续提供全面的技术支持。开发团队会向使用者提供迁移到新API的建议和帮助。部分功能支持阶段：API依然可用，但技术支持会减少甚至完全停止。开发团队不再提供新的功能或修复旧API的问题，鼓励用户尽快完成迁移。日落期策略使得API使用者有充分的时间来调整其应用程序，以适应新的API版本或其他替代方案。8.3

向智能化软件演进版权所有©️仅限于教学使用软件智能化的三个维度随着软件版本的不断更新，现代软件系统正逐步变得更加智能。这种智能化演进主要体现在以下三个方面：任务智能化：AI辅助开发者完成软件生命周期中的各项任务（如重构、修复）。功能智能化：软件集成LLM和AI能力，为用户提供智能化的新功能。过程智能化：软件开发和运维流程适应AI模型生命周期（如MLOps）。任务智能化：AI辅助开发与维护代码重构辅助：代码重构本质是“code-to-codegeneration”问题，大语言模型（LLM）在此领域显示巨大潜力。例如，EM-Assistant插件基于LLM，针对复杂的“LongMethod”代码异味提供“提取方法”的重构建议，其准确率和召回率均超过了基于机器学习和静态分析的同类工具。在以性能优化为目标的重构任务中，大模型表现出色，能实现平均6.86倍的速度提升，超过了人类程序员的平均水平（3.66倍）。遗留系统演化辅助：AI可辅助软件再工程（Softwarere-engineering）中的关键步骤。用于对遗留代码进行逆向工程，以提取原始的设计与需求。用于系统转变，例如将客户遗留的SAS数据分析代码自动转换为更现代化的Python或R代码。挑战：由于训练数据源于旧代码，大模型在代码生成任务中可能大量使用已弃用的API(DeprecatedAPI)。功能智能化Microsoft365Copilot：集成在Word、Excel、PowerPoint中，利用AI自动生成内容和进行数据分析，提高生产力。ZoomAICompanion：在会议和聊天平台中集成智能助手，自动生成会议摘要、实时聊天建议。JetBrainsAIAssistant：提供代码补全、文档生成、重构建议，以及协助解决版本控制冲突。CanvaMagicDesign：基于生成式AI，用户输入描述即可自动生成个性化设计模板。知乎“发现·AI搜索”功能：结合了传统搜索、实时问答和追问机制，基于知乎社区内的高质量内容，为用户提供结构化答案和相关问题拓展，提高知识探索的深度和连贯性。微博AI机器人：活跃于评论区，与用户进行互动，提高用户活跃度和积极参与感，提升用户粘性。过程智能化智能化新功能的加入，对传统的软件开发生命周期产生了转变。CI/CD工作流变化：不仅要处理代码构建和部署，还需要加入模型的数据准备、训练和评估模块，以确保智能化功能的有效性。AI模型的工作流逐步融入软件开