重构代码：如何避免写出过长的函数

大家刚开始编程的时候都会写几百行的函数，结果同事看得很头疼，最终不得不进行重构。

可是重构之前你必须深刻理解如何避免写出过长的代码，这样才能指导你以后的设计不再出现同样的问题。我归纳下来简单有2个原因：
1.做到事情太多，俗称职责太多。
2.层次复杂。

对于职责太多代码，就是拆分，这个其实还好理解。

比如一个用户注册的函数就包括了注册用户之外的太多功能，这里如果不隐藏代码细节的话，加起来代码肯定要超过100行了。

 function resisteUser(){
  //保存用户到数据库
  //更新用户标签
  //发送优惠券
  //发送通知
}

我们把每个单一的功能替换成一个函数，比如saveUserToDB就是把用户保存到数据库，这比注册用户能涵盖的职责要确定很多，同时把其他代码也封装成函数。

 function registeUser(){
  //保存用户到数据库
  saveUserToDB();
  //更新用户标签
  updateTag();
  //发送优惠券
  updateCoupon()；
 //发送通知
  notify();
}

这样看，registeUser是一个入口函数，他通过调用不同函数实现了用户注册，标签，通知全部的功能，每个函数功能单一，可读性增强了。

但是代码层次复杂， 很多人不能很好的去理解。

下面看一个很多行的代码，这个复杂吗？

if(name="a"){
log.info("hello, mr a,are u ok" )
}
if(name="b"){
log.info("hello, mr b, you are so good" )
}
//也许需求会一直加满a-z。。
if(name="z"){
log.info("hello, mr z, i dont like u. #$^$#^" )
}

可能你觉得这个代码很low，加一个判断条件都必须加一个if判断。
但是你好好思考，假如修改点无非是加一个字母，然后打印这个字母特定的输出信息,就算有100个分支，就算是给一个工作半年的程序员，他写出bug的可能性也是很低，为什么？

原因就是这个函数的功能层次很单一，每个分支做的事情都是判断条件，然后输出内容。

举例，业务功能和实现细节写在一起就是跨层次。

随便臆造一个业务场景，保存订单要先查询历史订单和执行保存订单。
1.保存订单和执行保存订单到mysql，重试和事务处理。
2.查询数据和解析查询结果，反序列化JSON加处理字符编码等。

坏的例子就是一个函数混合了业务操作和具体细节

function saveOrder(){
 //查询历史订单
  queryHistoryOrder();
  var res =  executeSaveDb();
  if(!res){
     log,error("保存失败");
     res = executeSaveDb();
  if(!res){
     saveToCache();
    }
  }
}

主函数只有核心操作，保存订单细节放到另外函数

function saveOrder(){
 //查询历史订单
  queryHistoryOrder();
//保存订单
  save();
}

function save(){
 var res =  executeSaveDb();
  if(!res){
     log,error("保存失败");
     res = executeSaveDb();
  if(!res){
     saveToCache();
    }
  }
}

大家都听过一句话，代码是给人看的；
对阅读这来说，代码业务点是第一重要，好的结构一眼就能恰当好的展示全貌，具体细节则是需要再去了解。