我为简短的回答向庞大的问题致歉。
真理啊，不要太留意我。
引言
模式和重构之间联系紧密，在一定程度上来说，设计模式的目的就是为许多重构行为提供目标。
在实际的项目开发中，一次到位是非常少见的事，无论时间是否充裕，第一版的代码往往单纯的以实现功能为目标。后续，如果有时间或者要求较高，可能会有一次，两次重构。如果是小企业兴许就会这么交差。然而对于我们开发者而言，长时间大量编写低质量代码假以时日就会变得只会写这种类型的代码，这对职业发展是不利的。
即使只以提升自身为目标，适当的了解有关代码重构的知识将对日后的开发工作大有脾益。
作为一个初级前端，本笔记旨在简单介绍一些重构的原则，目标，手段。会比较偏颇，只具备一定的参考价值。
这里重构主要针对JavaScript。
代码重构
提炼函数
函数是JavaScript的一等公民，平日的开发不是在和函数打交道就是在和对象打交道。
当然我知道函数也是一个对象，把它当对象来使用是毫无问题的，可以玩出很多花样。
针对函数有这么几点重构建议。
- 假如一个函数名本身就很长，包含了很多功能它就应该被重构。
- 可以独立出来的代码最好独立出来成为一个单独的函数，所谓拆分。
- 独立出来的函数需要良好的命名，它可以起到注释的作用。
举例来说
function getInfo(){
...//一段业务逻辑，也许是数据处理
$.ajax({
url:'xx',
data:'xx',
type:'post',
success:function(data){
...//一段业务逻辑，也许是数据处理和展示
}
})
}
//这是一个很常见的函数，如果有必要，它可以拆分成
function getInfo(){
handleData(data)
$.ajax({
url:'xx',
data:'xx',
type:'post',
success:showData
})
}
function handleData(data){
...//一段业务逻辑，也许是数据处理
}
function showData(data){
...//一段业务逻辑，也许是数据处理和展示
}
//就像我说的如果有必要..如果不需要考虑复用我会考虑把拆分出来的两个函数写到主函数里面去。
拆分出功能对于了解一个复杂函数内部在干什么很重要，同时维护分别的小函数，比维护一个大而复杂的函数要容易的多。
合并重复的条件片段
假如一个函数中有一些条件分支语句，而这些分支语句中有一些重复的语句，这样，我们就可以进行去重把这些重复语句提取出来。
这个没什么太多好说的很常见比如一个分页跳转。
function paging(currPage){
var jumpPage= 1;
if(currPage <=0){
jumpPage= 0;
jump(jumpPage)
}else if(currPage>totalpage){
jumpPage= 10
jump(jumpPage)
}else{
jumpPage=currPage
jump(jumpPage)
}
}
//虽然我个人认为不会有人写这么累赘的函数，这里只是为了举例可以把jump(jumpPage)提出来
function paging(currPage){
var jumpPage= 0;
if(currPage <=0){
jumpPage= 0;
}else if(currPage>totalpage){
jumpPage= 10
}else{
jumpPage=currPage
}
jump(jumpPage)
}
//类似这种感觉，只要是做数据前处理的，基本都以提出来
//如果有必要你可以把这里的重构成多态的形式，只是在这个例子里没有必要。
把条件分支语句提炼成函数
巨大而复杂的条件往往会使函数变得很难懂，简单来说就是把各种简单的小判断单独拉出来当作一个函数。
返回一个布尔值，通过这个布尔值来做判断。
例子:
function getInof(){
if(一串长而复杂的判断条件){
...//一串独立的处理代码
return result;
}
return result;
}
//这里就可以把那串判断条件提出来
function getInfo(){
if( judgeInfo()){
...//一串独立的处理代码
return result;
}
function judgeInfo(){
return //一串长而复杂的判断条件。
}
}
这样会使代码更好懂，当然不绝对，需要分情况讨论，在此不再展开。
合理使用循环
在一个庞大而复杂的函数体内其实有很多代码是负责的重复的工作，比如最常见的通过js直接对Dom元素进行赋值和取值这样的操作.
很多人会写出...
function setValue(){
document.getElementById('a').innerHTML='1';
document.getElementById('b').innerHTML='2';
document.getElementById('c').innerHTML='3';
.........
}
//这里只是举例它们有的时候可以有20~30行长，这是让人崩溃的。为什么不写一个简单的for in循环呢？
function setValue(){
var list={
a:1,
b:2,
c:3
}
for(i in list){
document.getElementById(i).innerHTML=list[i];
}
}
不仅减少了编码量，看起来更加优雅，还比较好懂，循环，你值得拥有。
合理的传参&&合理的退出&&合理的三目运算符
JavaScript函数的出口不一定非得限定为一个，虽然通常我喜欢让它只有一个出口使得结果更为可控。
但不一定每次都这样，比如进来一个判断，满足才需要往下执行的情况，我们就可以一进来不满足直接退出。这里需要灵活掌控。
关于参数，如果一个函数要接受很多参数，而你全部写上了，这无论是对扩展还是调用都很不利。
所以可以把它们写到一个对象中去。
一个简单的判断通常可以用三目来替代，比如给参数赋上默认值但是，如果复杂的If else也使用三目来替代代码会变得很不好懂，所以合理使用。
这里我无意举一个坏例子，只摆一个我认为合适的例子在这。
var param={
isExist:true,
age:12,
name:'tom',
vip:false
}
function setUserInof(param){
if(!param.isExist){
return 'notExist'
}
var vipState= param.vip || false
....//大量的业务逻辑，比如赋值什么的
return result;
}
大概就是这种感觉..坏的列子完全可以通过阅读上面的文字来反推。
关于合理的退出，假如内部有一堆循环，且需要判断到某个条件break的话，直接return效果更好，通常可以节约一些判断，且增加代码可读性。
合理使用链式调用
链式调用，使用过jQuery的话，对此不会陌生，每个操作之后可以直接跟下一个操作。
//就像这样
$('#user').text('tom').attr('display','block').css('font-size','28px')....
我在使用jQuery的时候听说这是被建议的，我见过一整个页面都是链式调用的代码，一个代码块可能有30~50行，每个链条隔了几百米远.....看起来似乎很高端？然而实际阅读起来，非常的不方便，而且没有必要，在这种情况下使用链式调用节省下来的字符数似乎相对原本的长度而言显得非常微不足道，我不知道为什么它要这么写。但这种代码修改起来非常的不友好，可以说是高度耦合的。
所以通常来说，如果结构稳定，使用链式调用似乎并没什么不妥。
但是如果这个代码很有可能需要扩展和修改，链式调用只会徒增修改的不便罢了。
结语
今天，稍微对代码重构进行了一些探讨，算是管中窥豹..
毕竟这一块展开来说可以出本书了。
实际上，这篇笔记让我来写有些空洞，因为基本上我没有对我写的模块进行大规模重构过。
充其量就是在项目时间充裕的时候精炼下写法罢了，然而通常项目时间并不充裕。
重构别人写的模块倒是有过几次，只是那些时候通常来说搞清楚它在干嘛然后自己写一遍会更快。
然而，并不是说这篇笔记就没有意义，虽然是现学现卖，但是这上面提到的重构原则，我在实践中通常会在编写时就考虑好，它们很基础，基础而有用。
这两天有点累，这篇笔记就到这里吧，相对之前的笔记篇幅可能略微有些短，这是为了便于补充。
于是在此暂时的，我放下了键盘。