重构四要素:目的、对象、时机和方法

本文主要是介绍重构四要素:目的、对象、时机和方法，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1.引言

2.重构的目的:为什么重构(why)

3.重构的对象:到底重构什么(what)

4.重构的时机:什么时候重构(when)

5.重构的方法:应该如何重构(how)

6.思考题

1.引言

一些软件工程师对为什么要重构(why)、到底重构什么(what)、什么时候重构(when)应该如何重构(how)等问题的理解不深，对重构没有系统行认识、在面对质量不佳的代码时，这些软件工程师没有足够的重构技巧，不能系统地进行重构、为了让读者对有清晰的认识，我们先来了解一下重构的目的、对象、时机和方法。

2.重构的目的:为什么重构(why)

软件设计专家 Martin Fowler 给出的重构的定义:“重构是一种对软件内部结构的改善，目的是在不改变软件对外部的可见行为的情况下，使其更易理解，修改成本更低。”在这个定义描述中，我们需要关注一点:“重构不改变对外部的可见行为”。注意，这里提到的“外部”是相对而言的。如果我们重构的是函数，那么函数的定义就是对外部的可见行为;如果我们重构的是一个类库，那么类库暴露的 API就是对外部的可见行为。在了解了重构的定义之后，我们探讨一下为什么要进行代码重构。

首先，重构是保证代码质量的有效手段，可有效避免代码质量下滑。随着技术的更新、需求的变化和人员的流动，代码质量可能存在下降的情况。如果此时没有人为代码的质量负责那么代码就会变得越来越混乱。当代码混乱到一定程度之后，项目的维护成本高于重新开发-套新代码的成本，此时再去重构就不现实了。

其次，高质量的代码不是设计出来的，而是迭代出来的。我们无法完全预测未来的需求也没有足够的精力和资源提前实现“未来可能需要实现的需求”，这就意味着，随着产品的选代、项目的推进和系统的演进，重构代码是不可避免的。

最后，重构是避免过度设计的有效手段，可以兜底暂时不完善的设计。在代码的维护过程中，当遇到问题时，我们再对代码进行重构，这样能有效避免前期的过度设计。

实际上，重构对软件工程师的技术成长也有重要意义。重构是设计原则和设计模式，以及代码规范等理论知识的重要应用场景。重构的过程能够锻炼我们熟练使用这些理论知识的能力。除此之外，重构能力是衡量软件工程师编码能力的重要手段。作者听过这样一句话:“初级软件工程师开发代码，高级软件工程师设计代码，资深软件工程师重构代码”，这句话的意思是:初级软件工程师在已有代码框架下修改、添加功能代码;高级软件工程师从零开始设计代码结构，搭建代码框架;而资深软件工程师为代码质量负责，能够及时发现代码中存在的间题，有针对性地对代码进行重构，时刻保证代码质量处于可控状态。

3.重构的对象:到底重构什么(what)

根据重构的规模，我们可以将重构笼统地分为大规模高层次重构(以下简称“大型面构”)和小规模低层次重构(以下简称”小型重构”)。

大型重构是指对顶层代码设计的重构包括对系统、模块、代码结构、类之间关系等的重构，大型重构的手段包括分层、模块化、解耦和抽象可复用组件等。大型重构的工具包括之前介绍的设计原则和第设计模式。大型重构涉及的代码改动较多，影响因此，其难度较大，耗时较长，引入bug的风险较高。

小型重构是指对代码细节的重构，主要是针对类、函数和变量等级别的重构，如规范命名、规范注释、消除超大类或函数、提取重复代码等。小型重构主要是通过之间介绍的规范来实现。小型重构需要修改之处集中，过程简单，可操作性较强，耗时较短，引入bug风险较低。读者只要熟练掌握各种代码规范，就可以在小型重构时得心应手。

4.重构的时机:什么时候重构(when)

在代码“烂”到一定程度之后，我们才进行重构吗?当然不是。如果代码已经出现维护难、bug频发等严重问题，那么重构已为时晚矣。

因此，我们不提倡平时不注重代码质量，随意添加或删除代码，实在维护不了了就重构甚至重写的行为。我们不要寄希望于代码“烂”到一定程度后通过重构解决所有问题。我们须探索一个可持续、可演进的重构方案。这个重构方案就是持续重构。

我们要培养持续重构的意识。我们应该像把单元测试、CodeReview(代码评审)作为开发的一部分一样，把持续重构也作为开发的一部分。如果持续重构成为一种开发习惯，并在队内形成共识，那么代码质量就有了保障。

5.重构的方法:应该如何重构(how)

前面提到，按照重构的规模，我们可以将重构笼统地分为大型重构和小型重构。对于这两种不同规模的重构，我们要区别对待。

大型重构涉及的代码较多，如果原有代码的质量较差，耦合度较高，那么重构时往往牵一发而动全身，程序员本来觉得可以很快完成的重构，结果有可能代码越改问题越多，导致短时间内无法完成重构，而新业务的开发又与重构冲突，最终，重构只能半途而废，程序员无奈地撤消之前所有的改动。

因此，在进行大型重构时，我们要提前制订完善的重构计划，有条不素地分阶段进行。每个阶段完成一小部分代码的重构，然后提交、测试和运行，没有问题之后，再进行下一阶段的宣构，保证代码仓库中的代码一直处于可运行的状态。在大型重构的每个阶段，我们都要控制重构影响的代码的范围，考虑如何兼容旧的代码逻辑，必要的时候提供实现兼容的过渡代码只有这样，我们才能让每一个阶段的重构都不会耗时太长(最好一天就能完成)，不与新功能的开发冲突。

大型重构一定是有组织的、有计划的和谨慎的，需要经验丰富、业务熟练的资深工程师主导，而小型重构的影响范围小，改动耗时短，因此，只要我们愿意并且有时间，随时都可以进行小型重构，实际上，除利用人工方式发现代码的质量问题以外，我们还可以借助成熟的代码分析工具(如Checkstyle、FindBugs和PMD等)自动发现代码中存在的问题，然后有针对性地进行重构。

在项目开发中;资深软件工程师、项目管理者要担负重构的责任，经常重构代码，保证代码的质量处于可控状态，避免引发“破窗效应”(只要一个人向项目中随意添加质量不高的代码，就会有更多的人往项目中添加更多质量不高的代码)。除此之外，我们要在团以内都营造一种追求代码质量的氛围，以此来驱动团队成员主动关注代码质量，进行持续重构。