关于代码重构的疑问

加参数判断！一个 if 连着一个 if，这叫封装！这叫代码复用！

软件设计有两种方式：一种是设计得极为简洁，明显没有缺陷；另一种是设计得极为复杂，没有明显的缺陷。第一种设计方式要难得多。

模块化原则就是：要编写复杂软件又不至于一塌糊涂的唯一方法，就是用定义清晰的接口把若干简单模块组合起来，这样一来，多数问题只在出现在局部，那么我们还有希望对局部进行改写或优化，不会牵一发而动全身。模块化代码的首要特质就是封装。封装良好的模块不会过多向外部披露自身的细节，不会直接调用其他模块的实现代码，也不是胡乱共享全局数据。模块之间通过 API ——一组严密的、定义良好的程序调用和数据结构来通行。

正交性是有助于使复杂设计也能紧凑的最重要的特性之一。在纯粹的正交设计中，任何操作均无副作用；每一个动作只改变一件事情，不会影响其它。无论你控制的是什么系统，改变每个属性的方法有且只有一个。重复的代码会导致前后矛盾，产生质量差的代码。原因是当你修改这些代码的时候，往往只修改了一部分而不是全部。

通常，这也意味着你对代码的组织没有想清楚。

软件是多层的。一般来说，设计函数或对象的层次结构可以选择两个方向——自顶向下和自底向上。一个方向是自底向上，就是从具体到抽象——先从要解决的问题中，确定要进行的具体操作，然后向上进行抽象。另一个方向是自顶向下，就是从抽象到具体——从最高层面描述整个项目的功能和逻辑，层层向下，直到各个具体的操作。实际代码往往是自顶向下和自底向上的综合产物，同一个项目中经常同时兼有自顶向下的代码和自底向上的代码，这就导致了「胶合层」的出现。

胶合层是个挺讨厌的东西，必须尽可能的薄，这一点极为重要。胶合层用来将东西粘在一起，但不应该用来隐藏各层的裂缝和不平整。

面向对象理念的价值最初在图形系统、图形用户界面和某些仿真程序中被认可。令大家惊讶并逐渐失望的是，我们很难发现面向对象在其他领域有多少显著的优点。面向对象语言让抽象变得很容易——有点太容易了。面向对象语言鼓励「厚重的胶合和复杂的层次」。所有的面向对象语言都显示出某种使程序员陷入过度分层陷阱的倾向。

代码简介之道里面推荐的方式是直接变成为五个函数，把函数间都共同需要的变量变成全局变量。如果这样导致全局变量过多的话，说明你的类也需要拆分了。

不要想太多，重构什么的 都是一步步来的

def foo
.step1
.step2
.step3
.step4
.step5
end

def bar
.step1
.step2
.step3
.step4
end

def step1; ... end
...
def step5; ... end

如果你对代码质量结构要求高的话，可以看看很多代码质量分析软件 or 规则。
比如 Ruby 下的 Rubocop 内置的代码分析规则规定，一个类不能超过 100 行，一个函数不能超过 10 行。
你可以根据实际情况相应调整自己的标准，然后对应重构你的代码。

具体问题具体分析啊。如果你这 5 个步骤比较复杂，本来就应该分 5 个函数来写。如果逻辑简单，你写一个函数里，后面再拆分也是正确操作。或者你业务经验较熟，一开始写的时候就知道这 5 个函数要拆分。重构不一定是代码写得烂，也有可能是需求变化。

代码量大拆，量小复制