让代码重构渐行渐远系列（1）——解除多层嵌套

重构背景及原因

　　最近由于项目组的人员在不断扩充，导致项目中代码风格各异，大有百花齐放甚至怒放之势。考虑到团队的生存与发展，经过众人多次舌战之后，最终决定项目组根据业务分成几个小分队，以加强团队管理与提高效率，同时也能培养阶梯人才。各个小分队为了“统一”代码风格，提高成员的代码能力以便最终能提高项目代码质量，减少以后的维护成本，最终决定“每日”进行小组内的代码走查/审查（Code Review），然后进行代码重构。

解除多层嵌套：我所谓的多层嵌套是指的如下代码：

 1  public bool 多层嵌套(string 参数一, string 参数二, string 参数三, string 参数四)
 2         {
 3             if (!string.IsNullOrEmpty(参数一))
 4             {
 5                 //此处省略   参数一的处理代码
 6
 7                 if (!string.IsNullOrEmpty(参数二))
 8                 {
 9                     //此处省略   参数二的处理代码
10
11                     if (!string.IsNullOrEmpty(参数三))
12                     {
13                         //此处省略   参数三的处理代码
14
15                         if (!string.IsNullOrEmpty(参数四))
16                         {
17                             //此处省略   参数四的处理代码
18                             return true;
19                         }
20                     }
21                 }
22             }
23
24             return false;
25         }

　　以上代码中一层层的嵌套着不仅增加了复杂度，也不利于阅读，尤其是当if条件下的处理逻辑代码过多时，几层嵌套下来第一层的IF包裹的代码量将相当大，也就增加了阅读的难度不利于以后维护了，尤其是其他人来维护。

　　可能有些朋友会说我的业务就如此我能怎么办，难道我要和客户说这个业务太复杂了，你们简单点吧等等........难道就真的没有办法呢吗？其实不然，毕竟办法总是有的，就看你愿不愿意想啦，那么我们该怎么处理这种代码呢？　　

　　其实根据不同场景我们也有不同的处理方式

场景一： 各个if条件互相不影响，或者说是不互相依赖时，可以像如下方式处理：

 1  public bool 解除多层嵌套方式二(string 参数一, string 参数二, string 参数三, string 参数四)
 2         {
 3             if (string.IsNullOrEmpty(参数一) || string.IsNullOrEmpty(参数二) || string.IsNullOrEmpty(参数三) || string.IsNullOrEmpty(参数四))
 4             {
 5                 return false;
 6             }
 7
 8             //此处省略   参数一,二,三,四的处理代码
 9
10             return false;
11         }

场景二：各个条件语句有先后循序互相依赖时，我们可以如下处理：

 1 public bool 解除多层嵌套方式一(string 参数一, string 参数二, string 参数三, string 参数四)
 2         {
 3             if (string.IsNullOrEmpty(参数一))
 4             {
 5                 return false;
 6             }
 7
 8             //此处省略   参数一的处理代码
 9
10             if (string.IsNullOrEmpty(参数二))
11             {
12                 return false;
13
14             }
15
16             //此处省略   参数二的处理代码
17
18             if (string.IsNullOrEmpty(参数三))
19             {
20                 return false;
21             }
22
23             //此处省略   参数三的处理代码
24
25             if (string.IsNullOrEmpty(参数四))
26             {
27                 return false;
28             }
29
30             //此处省略   参数四的处理代码
31
32             return true;
33
34         }

总结：

　　我们在开始写这种业务逻辑的时候，可能会不自觉的就写成了重构前的形式，导致一段时间后我们不得不再次熟悉代码，理解代码然后重构代码，那么我们为何不在写代码的时候，多多考虑下业务场景选择适合的方式呢？

　　如果我们在写代码的时候就考虑到了这些我们还需要再花时间做此种重构么？代码重构怎能不渐行渐远呢？