常见代码重构技巧（非常实用）

1_代码重构漫画jpeg

项目在不断演进过程中，代码不停地在堆砌。如果没有人为代码的质量负责，代码总是会往越来越混乱的方向演进。当混乱到一定程度之后，量变引起质变，项目的维护成本已经高过重新开发一套新代码的成本，想要再去重构，已经没有人能做到了。

造成这样的原因往往有以下几点：

对于此类问题，业界已有有很好的解决思路：通过持续不断的重构将代码中的“坏味道”清除掉。

重构一书的作者Martin Fowler对重构的定义：

根据重构的规模可以大致分为大型重构和小型重构：

大型重构 ：对顶层代码设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等等。这类重构的工具就是我们学习过的那些设计思想、原则和模式。这类重构涉及的代码改动会比较多，影响面会比较大，所以难度也较大，耗时会比较长，引入bug的风险也会相对比较大。

小型重构 ：对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名和注释、消除超大类或函数、提取重复代码等等。小型重构更多的是使用统一的编码规范。这类重构要修改的地方比较集中，比较简单，可 *** 作性较强，耗时会比较短，引入bug的风险相对来说也会比较小。什么时候重构 新功能开发、修bug或者代码review中出现“代码坏味道”，我们就应该及时进行重构。持续在日常开发中进行小重构，能够降低重构和测试的成本。

2_代码常见问题png

代码重复

方法过长

过大的类

逻辑分散

严重的情结依恋

数据泥团/基本类型偏执

不合理的继承体系

过多的条件判断

过长的参数列

临时变量过多

令人迷惑的暂时字段

纯数据类

不恰当的命名

过多的注释

3_代码质量如何衡量jpg

代码质量的评价有很强的主观性，描述代码质量的词汇也有很多，比如可读性、可维护性、灵活、优雅、简洁。这些词汇是从不同的维度去评价代码质量的。其中，可维护性、可读性、可扩展性又是提到最多的、最重要的三个评价标准。

要写出高质量代码，我们就需要掌握一些更加细化、更加能落地的编程方法论，这就包含面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。

4_SOLID原则png

一个类只负责完成一个职责或者功能，不要存在多于一种导致类变更的原因。

单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、松耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。

添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。

开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。

很多设计原则、设计思想、设计模式，都是以提高代码的扩展性为最终目的的。特别是 23 种经典设计模式，大部分都是为了解决代码的扩展性问题而总结出来的，都是以开闭原则为指导原则的。最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式（比如，装饰、策略、模板、职责链、状态）。

子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。

子类可以扩展父类的功能，但不能改变父类原有的功能

调用方不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。

高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

一个对象应该对其他对象保持最少的了解

尽量使用合成/聚合的方式，而不是使用继承。

单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，告诉我们要对扩展开放，对修改关闭。

imagepng

模块结构说明

代码开发要遵守各层的规范，并注意层级之间的依赖关系。

多个方法代码重复、方法中代码过长或者方法中的语句不在一个抽象层级。

方法是代码复用的最小粒度，方法过长不利于复用，可读性低，提炼方法往往是重构工作的第一步。

意图导向编程 ：把处理某件事的流程和具体做事的实现方式分开。

将函数放进一个单独对象中，如此一来局部变量就变成了对象内的字段。然后你可以在同一个对象中将这个大型函数分解为多个小型函数。

方法参数比较多时，将参数封装为参数对象

任何有返回值的方法，都不应该有副作用

临时变量仅使用一次或者取值逻辑成本很低的情况下

将复杂表达式（或其中一部分）的结果放进一个临时变量，以此变量名称来解释表达式用途

把复杂的条件表达式拆分成多个条件表达式，减少嵌套。嵌套了好几层的if - then-else语句，转换为多个if语句

当出现大量类型检查和判断时，if else（或switch）语句的体积会比较臃肿，这无疑降低了代码的可读性。 另外，if else（或switch）本身就是一个“变化点”，当需要扩展新的类型时，我们不得不追加if else（或switch）语句块，以及相应的逻辑，这无疑降低了程序的可扩展性，也违反了面向对象的开闭原则。

非正常业务状态的处理，使用抛出异常的方式代替返回错误码

某一段代码需要对程序状态做出某种假设，以断言明确表现这种假设。

当使用一个方法返回的对象时，而这个对象可能为空，这个时候需要对这个对象进行 *** 作前，需要进行判空，否则就会报空指针。当这种判断频繁的出现在各处代码之中，就会影响代码的美观程度和可读性，甚至增加Bug的几率。

空引用的问题在Java中无法避免，但可以通过代码编程技巧（引入空对象）来改善这一问题。

根据单一职责原则，一个类应该有明确的责任边界。但在实际工作中，类会不断的扩展。当给某个类添加一项新责任时，你会觉得不值得分离出一个单独的类。于是，随着责任不断增加，这个类包含了大量的数据和函数，逻辑复杂不易理解。

此时你需要考虑将哪些部分分离到一个单独的类中，可以依据高内聚低耦合的原则。如果某些数据和方法总是一起出现，或者某些数据经常同时变化，这就表明它们应该放到一个类中。另一种信号是类的子类化方式：如果你发现子类化只影响类的部分特性，或者类的特性需要以不同方式来子类化，这就意味着你需要分解原来的类。

继承使实现代码重用的有力手段，但这并非总是完成这项工作的最佳工具，使用不当会导致软件变得很脆弱。与方法调用不同的是，继承打破了封装性。子类依赖于其父类中特定功能的实现细节，如果父类的实现随着发行版本的不同而变化，子类可能会遭到破坏，即使他的代码完全没有改变。

举例说明，假设有一个程序使用HashSet，为了调优该程序的性能，需要统计HashSet自从它创建以来添加了多少个元素。为了提供该功能，我们编写一个HashSet的变体。

通过在新的类中增加一个私有域，它引用现有类的一个实例，这种设计被称为组合，因为现有的类变成了新类的一个组件。这样得到的类将会非常稳固，它不依赖现有类的实现细节。即使现有的类添加了新的方法，也不会影响新的类。许多设计模式使用就是这种套路，比如代理模式、装饰者模式

继承与组合如何取舍

Java提供了两种机制，可以用来定义允许多个实现的类型：接口和抽象类。自从Java8为接口增加缺省方法（default method），这两种机制都允许为实例方法提供实现。主要区别在于，为了实现由抽象类定义的类型，类必须称为抽象类的一个子类。因为Java只允许单继承，所以用抽象类作为类型定义受到了限制。

接口相比于抽象类的优势：

接口虽然提供了缺省方法，但接口仍有有以下局限性：

接口缺省方法的设计目的和优势在于：

为了接口的演化

可以减少第三方工具类的创建

可以避免创建基类

由于接口的局限性和设计目的的不同，接口并不能完全替换抽象类。但是通过对接口提供一个抽象的骨架实现类，可以把接口和抽象类的优点结合起来。 接口负责定义类型，或许还提供一些缺省方法，而骨架实现类则负责实现除基本类型接口方法之外，剩下的非基本类型接口方法。扩展骨架实现占了实现接口之外的大部分工作。这就是模板方法（Template Method）设计模式。

Image [5]png

接口Protocol：定义了RPC协议层两个主要的方法，export暴露服务和refer引用服务

抽象类AbstractProtocol：封装了暴露服务之后的Exporter和引用服务之后的Invoker实例，并实现了服务销毁的逻辑

具体实现类XxxProtocol：实现export暴露服务和refer引用服务具体逻辑

由于为了保持Java代码的兼容性，支持和原生态类型转换，并使用擦除机制实现的泛型。但是使用原生态类型就会失去泛型的优势，会受到编译器警告。

每一条警告都表示可能在运行时抛出ClassCastException异常。要尽最大的努力去消除这些警告。如果无法消除但是可以证明引起警告的代码是安全的，就可以在尽可能小的范围中，使用＠SuppressWarnings("unchecked")注解来禁止警告，但是要把禁止的原因记录下来。

参数化类型不支持协变的，即对于任何两个不同的类型Type1和Type2而言，List既不是List的子类型，也不是它的超类。为了解决这个问题，提高灵活性，Java提供了一种特殊的参数化类型，称作有限制的通配符类型，即List< extends E>和List< super E>。使用原则是producer-extends，consumer-super（PECS）。如果即是生产者，又是消费者，就没有必要使用通配符了。

还有一种特殊的无限制通配符List<>，表示某种类型但不确定。常用作泛型的引用，不可向其添加除Null以外的任何对象。

嵌套类（nested class）是指定义在另一个类的内部的类。 嵌套类存在的目的只是为了它的外部类提供服务，如果其他的环境也会用到的话，应该成为一个顶层类（top-level class）。 嵌套类有四种：静态成员类（static member class）、非静态成员类（nonstatic member class）、匿名类（anonymous class）和 局部类（local class）。除了第一种之外，其他三种都称为内部类（inner class）。

总而言之，这四种嵌套类都有自己的用途。假设这个嵌套类属于一个方法的内部，如果只需要在一个地方创建实例，并且已经有了一个预置的类型可以说明这个类的特征，就要把它做成匿名类。如果一个嵌套类需要在单个方法之外仍然可见，或者它太长了，不适合放在方法内部，就应该使用成员类。如果成员类的每个实例都需要一个指向其外围实例的引用，就要把成员类做成非静态的，否则就做成静态的。

通过对常见场景的代码逻辑进行抽象封装，形成相应的模板工具类，可以大大减少重复代码，专注于业务逻辑，提高代码质量。

面向对象编程相对于面向过程，多了实例化这一步，而对象的创建必须要指定具体类型。我们常见的做法是“哪里用到，就在哪里创建”，使用实例和创建实例的是同一段代码。这似乎使代码更具有可读性，但是某些情况下造成了不必要的耦合。

对于顶层的（非嵌套的）类和接口，只有两种的访问级别：包级私有的（没有public修饰）和公有的（public修饰）。

对于成员（实例/域、方法、嵌套类和嵌套接口）由四种的访问级别，可访问性如下递增：

正确地使用这些修饰符对于实现信息隐藏是非常关键的，原则就是：尽可能地使每个类和成员不被外界访问（私有或包级私有）。这样好处就是在以后的发行版本中，可以对它进行修改、替换或者删除，而无须担心会影响现有的客户端程序。

不可变类是指其实例不能被修改的类。每个实例中包含的所有信息都必须在创建该实例时提供，并在对象的整个生命周期内固定不变。不可变类好处就是简单易用、线程安全、可自由共享而不容易出错。Java平台类库中包含许多不可变的类，比如String、基本类型包装类、BigDecimal等。

为了使类成为不可变，要遵循下面五条规则：

可变性最小化的一些建议：

TDD的最终目标是整洁可用的代码（clean code that works）。大多数的开发者大部分时间无法得到整洁可用的代码。办法是分而治之。首先解决目标中的“可用”问题，然后再解决“代码的整洁”问题。这与体系结构驱动（architecture-driven）的开发相反。

采用TDD另一个好处就是让我们拥有一套伴随代码产生的详尽的自动化测试集。将来无论出于任何原因（需求、重构、性能改进）需要对代码进行维护时，在这套测试集的驱动下工作，我们代码将会一直是健壮的。

Image [6]png

添加一个测试 -> 运行所有测试并检查测试结果 -> 编写代码以通过测试 -> 运行所有测试且全部通过 -> 重构代码，以消除重复设计，优化设计结构

作者：VectorJin

1，对，__init__中定义的变量，其他对象方法（第一个参数是self的），可以直接用

2，不是很清楚你什么地方没想明白，三个参数都是update_screen的参数，作者认为它需要3个才能正确工作，就这么设计了。

3，ai_settings是一个实例，在图1的1处就是它了。

本篇文章 不是向您介绍任何最佳实践 或者使用 React 编写应用的某个“唯一方式”。

本文讲述的都是关于 React 中的 无状态函数式组件 (stateless functional component) 以及为什么它们可能有用或为什么应首先受到考虑。

在我们探讨这个问题之前，我们先了解一下在 React 上下文中函数式组件的定义。它本质上就是一个常规的函数，接收一个 props 并返回一个元素。

使用 ES6 的 箭头函数 和 解构 ，我们也可以这样编写：

初看，这与使用 createClass 和 ES6 Class 并没有什么特别之处，无状态函数式组件仅仅是一种编写风格。但是从我的观点来看却有很多不同。

现在让我们看一下函数式组件和基于类的方式的不同之处，并根据给定的事实，我们能推导出什么有价值的内容。

函数式组件，有时也被称为 无状态组件 ，没有任何生命周期方法，意味着每次上层组件树状态发生变更时它们都会重新渲染，这就是因为缺少 shouldComponentUpdate 方法导致的。这也同样意味着您不能定义某些基于组件挂载和卸载的行为。

更有趣的是您在函数式组件中既不能使用 this 关键字或访问到 ref 。对于习惯了严格意义上的类或面向对象风格的人来说，这很让他们惊讶。这也是使用函数最大的争论点。

另一个有趣的事实就是您仍然可以访问到 context ， 如果您将 context 定义为函数的一个 props 。

所以您可能会问自己，它的优势究竟体现在哪里。特别是您已经使用了 React 并倾向于使用基于类的方式。当我们拥抱这个概念的时候， 容器型组件 (container component) 和 展示型组件 (presentational component) 的概念就会变得非常清晰。您也可以阅读 Dan Abramov 关于此主题的 文章 以获取更深的了解。

通过将逻辑和数据处理与 UI 展示剥离开来，我们就可以避免在展示型组件中处理任何的状态。 无状态函数式组件强制实施了这样的风格 ，因为您无论如何都没有办法处理本地状态了。它强制您将任何的状态处理移交至上层的组件树，而让下层的组件只做它们所做的——关注 UI 的展示。

没有逻辑意味着相同的表示具有相同的数据。

在编写无状态函数式组件时，您需要避免某些特定的模式。避免在函数式组件中定义函数，这是因为每一次函数式组件被调用的时候，一个新的函数都会被创建。

这个问题很容易解决，您可以将这个函数作为 props 传递进去，或者将它定义在组件外面。

有时候谈起无状态函数式组件会提到 纯 (pure) 这个词。在这方面您应该避免使用 context 或 defaultProps，如果您需要定义上述任何一个或两个，您应该选择基于类的方式。

至于 defaultProps，一个变通的方案就是使用默认参数。

关于纯函数，请查看 Bernhard Gschwantner 的 评论 ，他总结得非常完美。

另一个常见陷阱就是简单地认为使用纯无状态函数式组件可以获得性能上的提升。这个观点是不正确的。 相反，当我们需要处理大量无状态函数型组件的时候，它的对立观点却是正确的。

性能问题是由于缺少生命周期方法导致的，这就意味着 React 没有访问任何额外的方法并且总是渲染组件。

缺少声明周期方法在另一方面也导致了没法定义 shouldComponentUpdate 方法。因此，我们不能够告诉 React 是重新渲染还是不渲染，这也就导致了永远都会重新渲染。接下来我们将会了解到缓解这种问题的方法。

如果您想了解更多高阶组件以及使用它们的优点，请查看 Why The Hipsters Recompose Everything 。

高阶组件是一种接收组件为参数并返回一个新的组件的函数。

这种方式可以让我们解决许多因使用无状态函数式组件而导致的问题。简言之，我们可以将函数式组件封装进高阶组件以解决状态处理和渲染优化这样的问题，高阶组件可以帮助我们关注本地状态处理以及 shouldComponentUpdate 函数的实现。

Recompose 就帮我们解决了以上提到的情况。

下面的这个例子是直接从这个项目 README 文件中拿来的。

正如上面所示，我们可以将精力集中于 UI 表示并在需要的时候将函数封装进一个纯函数并导出这个封装的函数。我们就不需要将原始的函数重构为一个类组件。

下面的示例来自于 Why The Hipsters Recompose Everything 。

withState 使得我们在有需要的时候管理本地组件状态，只需将我们的无状态函数式组件传递给 enhance 函数即可。

同样，recompose 已经实现了 withState ，所以就没有必要自己再去实现它了。

使用无状态函数式组件最大的好处就是它能够将容器型和展示型组件明确区分开来，避免产生大型以及杂乱的组件。没有 this 关键字也就意味着没有快捷方式在整个应用中随机地展开状态。

当一个开发团队中人员经验存在差别时，这些方面就会变得异常有用，它会帮助我们间接地执行内部开发的标准。

分离与重构是软件工程中的两个概念。

分离（Separation）指将一个系统或模块中不同职责的部分进行拆分，使得每个部分只负责一项特定的功能。这样可以提高代码可读性、可维护性和可扩展性，并降低耦合度。常见的实现方式包括面向对象编程中的单一职责原则、开闭原则等。

重构（Refactoring）指在不改变程序外在行为情况下对代码进行优化和调整，以提高其内部结构、清晰度和灵活性。通过重构可以消除代码中存在的坏味道，如长方法、复杂逻辑等问题，并增强代码健壮性和可维护性。常见的重构手段包括函数/类/模块抽象、参数传递简化等。

总之，分离与重构都是为了让软件更加易于理解、修改和扩展，在软件开发过程中具有非常重要的作用。