大家刚开始编程的时候都会写几百行的函数，结果同事看得很头疼，最终不得不进行重构。
可是重构之前你必须深刻理解如何避免写出过长的代码，这样才能指导你以后的设计不再出现同样的问题。我归纳下来简单有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();
}
}
}
大家都听过一句话，代码是给人看的；
对阅读这来说，代码业务点是第一重要，好的结构一眼就能恰当好的展示全貌，具体细节则是需要再去了解。
