代码写来是用来读的

今天读了一些业务相关的代码，有一个类的方法达到了400多行，里面很多的判断语句，最多的if嵌套深度到达了5层，其实整个方法的业务逻辑并不是很复 杂，就是对调用请求进行一些检查，然后在每种情况下进行一些不同的处理，而且这些处理都比较的简单，但是糅合在一起的代码。却很多的问题
一、很难直白的理解方法的意图
    虽然你可以从if语句的判断条件中读懂整个执行流程，但是这还是很费力的，如果碰到变量名取得不好，或者if判断中间是N个条件的组合判断，你就很难读了。
二、为方法增加新的逻辑之后就很困难而且容易出错
    在众多的判断逻辑中要增加新的逻辑，最大的成本在于你要先读懂原有逻辑，最好是画出原有方法的顺序图，然后基于这个顺序图再来添加新的逻辑，但是基本上是不会有人这么做的，所以添加新的逻辑处理的时候，就基本上是Bug数量迅速增长的时候。
三、方法难以测试
    因为判断逻辑很多，导致代码的执行路径很多，在编写测试用例的时候，做到路径覆盖也是很困难的。而且一旦方法的处理逻辑改变了比较大，基本上所有的测试用例都得重写。
问题肯定还是很多的，简单的重构的方向
一、将判断逻辑封装成方法
    这是最直接的想法，其实就是将复杂的处理逻辑分解成一个个小方法，然后再拼装起来，这样就可以克服上述3个缺点，如果封装的方法名取得得当，那么你就不需 要读懂if的复杂判断语句来理解方法所表达的业务处理逻辑，与此代码的增加新的逻辑就简单了，在较小的方法中进行修改就相对容易多了，但并不是绝对的。
二、利用面向对象进行更深层次的封装
    如果代码中到处都是if的判断语句，那显然是面向过程的痕迹很重，我们可以深入的分析，将设计变得更加面向对象，对对象职责的细分，对象方法处理逻辑的简 化，对象之间的交互更简单直接些。其实这未必更加简单，需要付出的设计、重构的代价也很大。理解更多的对象之间的交互也不是一件简单的事情，但是在可扩展 性方面就更好。

    没有拿实例代码来说明，但是道理还是很简单的，如果想要较小的成本在短时间内进行重构，那么就采用第一种方法，将判断逻辑封装成方法。想要在一个大的系统内得到更好的重构效果，就要重新考虑设计，进行设计到代码两层次的重构。