让我们回到重构的基本概念，想想我们需要如何重构辅助服务。 1.后台代码重构是每个开发人员最熟悉的词汇，它的出现通常伴随着开发过程。 在漫长的程序开发、迭代和进化过程中，一个不经意的修改就可能破坏程序原有的设计和结构，导致代码结构的丢失，这是累积的。如果不及时发现和重建，程序会逐渐腐烂甚至变质，形成巨大的历史欠账。 其实重建就像打扫房间一样。如果我们每天都打扫的话，那么每天打扫就要花3分钟。但是如果我们一个月不打扫，你觉得要多久才能打扫完？ 既然代码重构在开发过程中如此重要，没有相应的服务如何支持？我们能不能开发一个相应的扫把，每天帮我们打扫房间？还是“扫地机器人”自动帮我们打扫一个月没打扫的房间？带着以上问题，让我们回到重构的基本概念，思考一下我们需要如何重构辅助服务。 1.什么是重构？如本书所述，重构是在不改变程序外部行为的情况下，修改代码以改善程序内部结构的过程。 这里的重构有两个意思，一个名词意思，一个动词意思:重构(名词):对软件内部结构的调整，目的是在不改变其可观察行为的情况下，提高其可理解性，降低其修改成本。 重构(动词):使用一系列重构技术来调整软件的结构，而不改变其可观察到的行为。 至此，我们应该明白，一个好的重构助手服务至少应该具备不变性和可变性两个特征:不改变软件的可观察行为；优化代码结构，降低修改成本，提高可理解性。 2.何时重构(何时重构，如何重构)，业内讨论激烈。有人认为重构应该随时随地进行，不应该为了重构而重构。例如，当我添加新功能、修复bug或审查代码时，我可以重构。我们暂且称之为“开发时重构”。还有人认为“增加新功能”和“重构”是两顶帽子。你不应该修改现有的代码，只增加新的功能，但是重构的时候，不能增加功能，只是改进程序结构，一次做一件事。我们暂且称之为“维护重构”。 个人认为这两种说法并不矛盾。真正好的重建应该是两者的有机结合。 如上图，红色范围在我看来是一个很好的重构实践。 我觉得无论是开发新功能还是维护旧版本都适合代码重构，只是合适的重构粒度不一样。 对于开发时的重构，更适合个人层面的小规模微重构。这种重构往往影响范围小，相对简单，不会给开发增加难度，比如“重命名”、“函数提取”之类的原子重构。对于维护时重构，更适合架构层面的大规模复杂重构。这种重构常用于解决项目代码中遗留的技术债务，通常与消除代码的不良味道相结合，如特性羡慕、数据丛生等。，而这些恶趣味重构往往是由一系列重构原子操作组合而成的。 当然，最好在开发阶段就尽可能多地进行重构，尽量减少新增代码对现有设计和架构的破坏。 看到这里，我们是不是有些似曾相识，对应着上面提到的“扫帚”和“扫地机器人”在实际重建工作中的应用？3.为什么需要代码智能重构服务？使用过现代ide开发代码的同学应该都知道，以IntelliJ IDEA为代表的很多IDE都附带了少量的重构功能，但是到目前为止，这些重构都是“重命名”、“函数提取”等原子重构，只对重构过程提供了部分支持。代码和架构的大部分重构工作仍然要手工完成，就像你需要打扫一个月没打扫的房子，但是 肯特·贝克(Kent Beck)表示，“手动重建仍然是一项耗时的任务。 正是这个简单的事实使得许多程序愿意重构。虽然他们知道应该重构，但是重构的成本太高了。 如果重构可以做到像调整代码格式一样简单，程序员自然会愿意像整理代码格式一样整理系统设计。 这种安排将对代码的可读性、可重用性和可理解性产生深远的积极影响。 正因为如此，一个能够帮助开发者发现代码和架构中的恶趣味，引导开发者完成代码重构的智能服务就显得尤为重要。 二。Devops全流程下的重构服务需求对于持续交付过程中的代码开发和发布环节，如上图虚线框所示，几乎每一步都与代码质量关怀或代码重构有关。 开发环节大致可以分为两种:添加新功能的“增量开发”和维护旧版本的“存量维护”。 对于“增量开发”，需要重构服务的代码规范重构和原子重构能力，帮助开发者在开发过程中提高代码质量和开发效率；对于“存量整改”，要求重构服务应具备架构和代码的恶趣味检查能力，挖掘重构的机会点并推荐重构方案，将相应的重构方案拆解为独立正交的原子重构能力，最终作为原子重构序列推荐给开发者，在人机交互中一步步完成重构应用。 在持续释放过程中，MR门禁中的静态码检测需要触发不良味道码的识别。作为一种增量检测，主要识别新增代码引入的代码和架构的不良味道，自动生成一个重构任务，引导开发者做一次重构，避免代码中技术债的积累。 在生产运维过程中，需要定期的架构关怀，通过架构可视化图形界面展示相应的测量结果。当架构的某个模块衰减到某个阈值时，会自动报警，提醒版本负责人进行相应的重构。 3.如何帮助开发者实现代码分层重构？1.有哪些层次的重构？我个人认为重构大致可以分为四个层次。从上图可以看出，这些层次之间的关系不是自下而上的，而是相互之间有一些重叠，也有一些区别。 从纯重构本身来看，重构级别越高，越不确定，越专业，而重构级别越低，越确定，越专业。 从智能重构服务的角度来看，级别越高，检测能力越偏，级别越低，重构能力越纯。 我们先来看看自下而上不同层次的重构操作的特点和异同。 原子重构能力:原子重构在上面的文章中也有提及。什么是原子重构？顾名思义，就是不可分割的重构操作，比如重命名、移动、删除。这些重构操作是完全确定的。比如我要提取一段代码形成一个新方法，能不能提取出来是完全确定的。 这些重构操作因其不可分离性而处于重构的底层。 代码重构:一些学生可能不熟悉这种级别的重构。其实就是基于规范和规则的重构，通常包括我们所说的微重构，比如对违反命名风格的标识符进行重命名，或者安全删除无用的代码等。，而这一级别的重构完全可以通过调用下层的一个atom重构来实现。 因为这些重建操作是基于规则的，所以它们的重建结果是相对确定的。 代码恶趣味重构:代码恶趣味还包括架构恶趣味，比如特性羡慕，神级等。这些层次重构的目的是消除代码相应的不良味道，所以相对复杂。一次重构的完成往往会调用下级的多次原子重构操作，比如重构神类，至少需要一次Extract类的原子重构。 同时，这一层重构的不确定性也更高，有很多方法可以消除一段代码的不良味道。 设计模式恶趣味重构:这一层重构应该属于金字塔顶端的重构。因为涉及面广，更倾向于对业务的理解和预测，从具体到一般多少有些虚幻。 设计模式中有7个坏口味和11个标准。目前，学术界和工业界对此类问题的检测和重建研究很少。 2.智能重构服务在不同层次的应用。结合Devops下重构服务的需求和上图所示的四级重构，基本可以看出不同级别智能重构服务的重构能力主要用在开发工作流程的哪个阶段。 对于原子重构，由于其确定性和业务独立性，最适合作为插件集成到IDE中，在做增量开发时由开发人员调用；对于代码规范重构，适合与原子重构一起集成到IDE插件中，可以自动快速识别开发过程中违反特定规则的代码，辅助开发者进行重构；对于代码恶趣味重构，适合在持续发布的访问控制阶段封杀问题，引导开发者回到ide进行代码智能重构；对于设计模式恶趣味重构，因为涉及到业务理解和预测，所以更适合生产运维。结合版本演化和迭代历史，给出了架构损坏的预测和相应的重构方案推荐。 3.积木式重构应用既然所有的上层重构操作都可以转化为最底层的原子重构操作，那么这种转化如何表达呢？该表列出了几种常见的重构原子操作，每种重构原子操作都可以用一个函数来表示。 比如Move Method，函数名就是Move Method。我们使用三个参数来阐明它的行为:源(类型)、目标(类型)和(要移动的方法)。有了这些信息，我们可以一次阐明Move方法的原子重构。 对于任何复杂的重构，都可以表示为以下原子重构序列，即一系列原子重构的组合。 就像积木一样，任何上层的重构都可以通过积木组合下层的原子重构来实现。 四。重构服务的设计标准。重构服务的设计与许多其他开发服务一样。最终目的是提高客户开发效率和代码质量。如果两者都不能保证，这个服务就永远被扔进垃圾堆了。 从我们在华为的实践经验中总结出以下原则:充分的客户交互:经典的重构工作流程是“小步前进，随时可用，随时停止，随时回滚”。小步修改意味着每一步出错的可能性大大降低。要遵循这个过程，离不开工具和客户的频繁交互。要引导客户一步一步完成复杂的代码重构，每一个过程都要随时可用，随时停止，随时回滚。 友好的重构界面:代码重构类似于代码自动修复，但涉及的范围比代码自动修复更广。让客户表达重构意图，一目了然地看到重构对原代码架构的影响，是非常重要的。这部分有很多创新。 个性化客户配置:上层重构往往可以有不同的执行路径，同样的恶趣味重构，根据不同的代码项目和业务场景，实现也可能不同。我们要以客户为中心，根据不同的业务和客户，给出个性化、定制化的重构解决方案，而这恰好是AI擅长的领域。 Devops服务的深度整合:任何开发服务离开Devops服务都会成为一个孤立的分散点，在开发过程中无法顺利使用。如果我们能够将重构服务集成到IDE、代码检查、代码仓库、验证和发布中，我们就可以在可信开发中使用重构工具。 高效:尤其适用于在IDE上重构分析服务。如果分析过程耗时太长，程序员很可能不会使用这些重构服务，他们更喜欢手动重构。