从小重构说起

首先要说的是重构最基本的定义：重构是在不敢编软件可观察行为的前提下改善其内部结构。

每一个开发人员肯定都经历过『坏代码』的味道。在一个古老又庞大的项目中，这里面一些函数的作用和逻辑变的很难理解，没有人了解这里的所有 case，加上没有足够的注释，之前开发的人员离职等诸多因素，可维护性非常低，谁都不愿意碰，这时候再改动一个需求，会很容易引入一些 bug。当你遇到上面的这些情况时那么时候要把这摊『臭水坑』清理一番了。

我们知道要做重构这件事了，那么『工欲善其事必先利其器』，重构也是有诸多手段的，有许多被前人验证过的重构手法来帮助我们改善项目代码的健康状况。接下来讲讲一些小的也是简单实现的重构方式。

小重构

重复的代码

重复代码的抽象有几种方式，一种是将重复的代码或者相似的代码，可以提取到一个扩展函数中，然后在多个地方调用；或者将多个相似类中的相同代码抽象到父类中，子类调用，但是按照组合优于继承的设计方式，不建议这样做；再有是对相似流程代码抽象出模板方法，子类实现差异化逻辑。

过长的函数

在计算机领域有这样一句名言：『计算机科学相信所有问题都可以通过添加一个间接层来解决』。如果我们没有良好的系统设计经验和深刻理解面向对象思想（业务系统主流的编程思想），就很容按照过程式的思想去写代码，就会出现职责庞大的函数或类，有着超多的分支判断逻辑，各种补丁代码块。这里一部分是系统设计的问题，另一方面没有很好的拆分职责。一个很好的办法就是将分支中的代码块抽离成小函数，把大类拆分成职责较为单一的小类。再有让小函数容易理解的关键是一个好名字（关于起名字这块可以单独说说）；再有大函数中的临时变量可能阻碍你的拆分，可以把这些临时变量通过查询的方式获取，既提高了可读性又能共享给其它地方用。

过大的类

过大的类就像过长的函数，冗杂且难以理解。我们通俗的说这个类的职责太重了，导致里面又很多的实例变量。改造的办法是将多个实例变量分组，然后拆分不同的类去处理，这样来拆分出一些单一职责类。再有就是可以确定类的使用方式，提炼出来接口帮助理解这个类。

过长的参数列表

过长的参数列表可能是这样产生，最初定义接口只有两个参数，那么随着业务扩展，这个函数产生的职责越来越大，随之参数越加越多。这种的解决方案是搞一个参数对象，将原先的参数都保存到参数对象实例中，然后传递这个实例到函数中处理。

然后呢

我把这写最基本的风险小的方式叫做小重构，可以让我们的代码变得稍微好一些。其实你在做小重构的过程中可以慢慢形成对于这个系统业务流程的理解，以及对于系统设计（大）重构方向上的思路。那么什么时候或者什么时机就要开始重构？

如果让我接需求改系统一个部分的代码，做完如果再次需求改动不是很容易改的时候，基于事不过三的原则，我会在需求中做一些重构来弥补设计上的缺陷；再有就是修复 bug 的时候，如果不是很好修复，我也是要先进行适当的重构的再去解决的；或者我们集中进行 codereview 的时候提出来需要进行的重构时。

一个好的项目是需要有一个好的设计基础，因为我们不能只想着今天做什么，还要想明天可能会做什么，只做好今天，而明天到来发现无法做到，那么也是失败的，想的多了就会出现过度设计，也是包袱。所以写好代码是一件挺难的事情，写之前多思考一下。今天先写这么多～