摘要：让咱们再回到重构的基本概念，思考咱们须要怎么的重构辅助服务。
一、背景
代码重构是每一位开发者最相熟不过的字眼，其呈现通常随同着开发过程。在程序开发、迭代与演进的漫漫长路中，某次不经意的批改就可能毁坏程序原有的设计与构造，造成代码构造的散失，而这种散失是具备累积性的，若未及时发现与重构，程序就会逐步腐烂甚至变质，造成微小的历史债权。其实重构就好比拾掇房间，如果咱们天天清扫，那么每天花 3 分钟就能清扫洁净，可如果一个月不清扫，你想想须要多久能力清扫完。
既然代码重构在开发过程中这么重要，怎么能没有相应的服务来撑持它呢？咱们能不能开发出相应的 “扫帚”辅助咱们每天清扫房间？亦或是“ 扫地机器人”主动的帮咱们清扫一个月未拾掇的房间？
带着上述疑难，让咱们再回到重构的基本概念，思考咱们须要怎么的重构辅助服务。
1. 什么是重构
如此书中所说，所谓重构（Refactoring）是这样一个过程：在不扭转代码外在行为的前提下，对代码做出批改，以改良程序的内部结构。这里的重构有两层含意，一个名词含意，一个动词含意：
重构（名词）：对软件内部结构的一种调整，目标是在不扭转软件可察看行为的前提下，进步其可了解性，升高其批改老本。
重构（动词）：应用一系列重构手法，在不扭转软件可察看行为的前提下，调整其构造。
至此，咱们应该明确，一款好的重构辅助服务应该至多兼具不变与变两个特色：不扭转软件可观测行为；优化代码构造，升高批改老本，进步可了解性。
2. 什么时候重构（何时应做怎么的重构）
就重构机会问题，业界也有比拟强烈的探讨，有人认为重构应该随时随地地进行，不应该为了重构而重构，就比方我在增加新性能时、修补谬误时、或者复审代码时都能够进行重构，咱们暂且称之为“开发时重构”，也有人认为“增加新性能”和“重构”是两顶帽子，在增加新性能时，就不应该批改既有代码，只管增加新性能，而在重构时，就不能增加性能，只管改良程序结构，一次只做一件事，咱们暂且称之为“保护式重构”。我集体认为这两种说法并不矛盾，真正好的重构应该是两者的有机联合。
如上图所示，红色范畴是我认为比拟好的重构实际。
我认为无论在做新性能开发时还是在做老版本保护时，都适宜做代码重构，只是适宜的重构粒度不同而已。对于开发时重构，比拟适宜做集体级小范畴的微重构，这种重构往往影响范畴小，且较为简单，不会对开发减少工作难度，例如“重命名”、“函数提取”等原子重构；对于保护时重构，比拟适宜做架构级大范畴的简单重构，这种重构往往是为了解决我的项目代码中遗留的技术债权，且通常和代码坏滋味的打消联合在一起，例如依恋情结（Feature Envy）、数据泥团（Data Clumps）等，而这些坏滋味的重构往往由一系列的重构原子操作组合而成。当然，最好将重构工作尽可能多地做在开发阶段，尽量减少新增代码对已有设计与架构的毁坏。
看到这里，咱们是否有些似曾相识，这不就对应了上文中提到的“扫帚”以及“扫地机器人”在理论重构工作中的利用？
3. 为什么须要代码智能重构服务
应用过古代 IDE 开发代码的同学们应该都晓得，以 IntelliJ IDEA 为代表的很多 IDE 多少都自带一些重构性能，但目前为止，这些重构都是例如“重命名”、“函数提取”等原子性重构，只对重构过程提供了局部反对，绝大部分的代码、架构坏滋味重构工作依然得靠手工实现，就好比你须要清扫一个月未清扫的房子，但手中只有一把扫帚一样。Kent Beck 说过：“手工重构依然是很耗时的工作。正是这个简略的事实造成了很多程序愿不愿意进行重构，只管他们晓得本人应该重构，但毕竟重构的老本太大了。如果可能把重构变的像调整代码格局那么简略，程序员天然也会乐意像整顿代码格局那样整顿零碎的设计。而这样的整顿对代码的可读性、可复用性和可了解性，都能带来深远的侧面影响。”正因如此，一款智能的、能够帮忙开发者发现代码、架构中的坏滋味并且疏导开发者实现代码重构的服务尤为重要。
二、Devops 全流程下的重构服务需要
对于继续交付过程中的代码开发与公布环节，如上图虚线框所示，简直每一步都与代码品质的看护或代码重构相干。
- 开发环节 可大抵分为两种类型：用于增加新性能的“增量式开发”以及保护老版本的“存量式保护”。对于“增量式开发”而言，须要重构服务的编码标准重构和原子重构能力在开发过程中帮忙开发人员晋升代码品质与开发效率；对于“存量式整改”而言，则须要重构服务具备架构、代码坏滋味的查看、重构机会点开掘以及重构计划的举荐能力，并将相应的重构计划拆解为彼此独立且正交的原子重构能力，最终作为一个原子重构序列举荐给开发人员，在与人机交互中一步步实现重构利用。
- 在 继续公布环节，MR 门禁中的代码动态检测须要触发对坏滋味代码的辨认，作为一种增量式检测，次要辨认由新增代码引入的代码及架构坏滋味，并主动生成一次重构工作，疏导开发人员进行一次重构，防止代码中技术债沉积。
- 在 生产运维环节，须要做定期的架构看护，将相应度量后果通过架构可视化图形界面展现进去，当架构某个模块腐化到一个阈值时主动报警，提醒版本负责人做相应重构。
三、如何辅助开发人员实现代码分层重构
1. 都有哪些层级的重构
集体认为重构大抵能够分为 4 个层级，这些层级之间的关系能够从上图看出，并非是自底向上顺次蕴含的关系，它们之间会有些重叠也有些不同。单纯从重构自身来讲，越上层级的重构操作非确定性越强，更偏业务性，而越下层级的重构操作确定性越强，更偏技术性。从智能重构服务的角度来讲，越下层越偏检测能力，越上层越偏纯重构能力。上面咱们由下至上顺次来看看不同层级重构操作的特点与异同。
原子重构能力：上文中也有提到原子重构，原子重构到底有哪些呢？顾名思义，即不可再分的重构操作，例如重命名、挪动、删除等重构操作，这些重构操作是齐全确定性的，例如我想要抽取一段代码造成一个新办法，是否可抽，能够抽成什么样都是齐全确定的。这些重构操作因为其不可再分性位于重构最底层。
编码标准重构：有些同学可能会对这个层级的重构比拟生疏，其实它就是基于标准和规定的重构，通常蕴含了咱们所说的微重构，例如对违反了命名格调的标识符进行重命名重构，亦或是对无用代码进行删除的平安删除重构等等，并且这层的重构操作齐全能够通过调用上层的 1 个原子重构来实现。正因为这些重构操作基于规定，其重构后果也是绝对确定的。
代码坏滋味重构：代码坏滋味也包含了架构坏滋味，例如 Feature Envy、God Class 等类型，这些层级重构的目标是为了打消相应的代码坏滋味，所以相对来说更简单，一次重构的实现往往要调用上层多个原子重构操作，例如对 God Class 进行重构，须要调用至多一次 Extract Class 原子重构。同时这层重构的非确定性也更高，对一种代码坏滋味的重构打消往往能够通过多种手段。
设计模式坏滋味重构：这层重构应该属于金字塔顶端的重构，因为它波及范畴太广，更偏差于对业务的了解与预测，从具象到形象，显得有些扑朔迷离。设计模式有 7 中坏滋味和 11 中准则，目前无论学术界还是工业界对于这类问题检测、重构相干的钻研都还不多。
2. 智能重构服务在不同层级下的利用
联合 Devops 下的重构服务需要与上图中的四层重构，咱们根本能够看出智能重构服务不同层级的重构能力次要使用在开发工作流中的哪个阶段。对于原子重构来说，因为其确定性以及业务无关性，最适宜作为插件集成在 IDE 上，由开发者做增量开发时调用；对于编码标准重构来说，适宜同原子重构一起集成进 IDE 插件，在开发过程中主动且疾速的辨认到违反特定规定的代码，并辅助开发者重构；对于代码坏滋味重构来说，适宜在继续公布环节的门禁阶段拦挡问题并疏导开发者回到 IDE 进行代码智能重构；对于设计模式坏滋味重构来说，因为其波及业务了解与预测，更适宜放进生产运维环节，联合版本演进与迭代历史，给出架构腐化的预测以及相应重构计划的举荐。
3. 搭积木式的重构利用
既然下层重构操作都能够转化为最底层的原子重构操作，那如何表白这种转化呢？表格中列举了几种常见的重构原子操作，每种重构原子操作都能够用一个函数来表白。例如 Move Method，函数名为 Move Method，咱们用三个参数来明确它的行为：Source（所属类型）、Target（指标类型）以及（须要挪动的办法），有了这些信息就能够明确一次 Move Method 原子重构。对于任何一个简单的重构来说，都能够示意成如下模式的原子重构序列，即一系列原子重构的组合。
就像搭积木一样，任何下层重构都能够通过搭积木的形式组合底层原子重构来实现。
四、重构服务设计准则
重构服务的设计亦如其它很多开发服务一样，最终目标都是晋升用户开发效率与代码品质，如果二者皆得不到保障，那这款服务将被永远丢进垃圾堆里。从咱们在华为外部的实践经验，总结了以下几点准则：
充沛的用户交互：经典的重构工作流程为 “小步后退，随时可用，随时可停，随时回退”，小步批改意味着每一步出错的可能性大大减小，要遵循这个流程，就离不开工具和用户频繁的交互，要疏导用户一步步的实现简单的代码重构，每个过程都要做到 随时可用，随时可停，随时可退。
敌对的重构工作界面：代码重构有点相似代码主动修复，但比代码主动修复波及范畴更广，如何让用户更好的表白重构用意、并且高深莫测的看到重构对原代码架构的影响十分重要，这一部分有很多能够翻新的中央。
个性化用户配置：上层级的重构往往能够有不同的执行门路，依据代码工程不同、业务场景不同，同一种坏滋味重构的实现形式也可能不同，要以用户为核心，依据业务不同、用户不同给出个性化、定制化的重构解决方案，这一部分刚好是 AI 善于的畛域。
Devops 服务深度集成：任何一款开发服务如果来到 Devops 服务就会成为一个孤立的散点，无奈在开发过程中被顺畅的应用，如果咱们能把重构服务集成进 IDE、代码检视环节、代码入库环节以及验证公布环节，就能够让重构工具 Build In 在可信开发过程中，让重构服务触手可及。
高效：特地是在 IDE 上的重构剖析服务，如果剖析过程须要破费太长时间，程序员很可能就不会应用这些重构服务，他们宁肯手工重构。
点击关注，第一工夫理解华为云陈腐技术~