关于重构

代码坏味道
1）Duplicated Code(重复的代码)
2）Long Method(过长函数)
3）Large Class(过大类)
4）Long Parameter List(过长参数列)
5）Divergent Change(发散式变化)
6）Shotgun Surgery(霰弹式修改)
7）Feature Envy(依恋情结)
8）Data Clumps(数据泥团)
9）Primitive Obsession(基本型别偏执)
10）Switch Statements(switch语句)
11）Parallel Inheritance Hierarchies(平等继承体系)
12）Lazy Class(冗赘类)
13）Speculative Generality(夸夸其谈未来性)
14）Temporary Field(令人迷惑的暂时值域)
15）Message Chains(过度耦合的消息链)
16）Middle Man(中间转手人)
17）Inappropriate Intimacy(狎昵关系)
18）Alternative Classes with Different Interfaces(异曲同工的类)
19）Incomplete Library Class(不完美的程序库类)
20）Data Class(幼稚的数据类)
21）Refused Bequest(被拒绝的遗赠)
22）Comments(过多的注释)

关于重构
1）最好的设计经常是在编码阶段产生的
2）好的程序员应该写出人能懂的代码
3）函数设计第一原则：短小
4）函数应该做一件事、只做这件事、做好这件事
5）OOP：Tell,Don't Ask；告拆对象你希望它们做什么事情，而不是询问它们的状态后再做出决定，最后才告拆它们做什么事情
6）变化和不变的东西分离出来、针对接口而不是实现编程、多用组合少用继承
7）包：无环依赖原则

惯性定律
1）惯性定律：好的代码会促生好的代码，糟糕的代码也会促生糟糕的代码。别低估了惯性的力量。没人想去整理糟糕的代码，同样没人想把完美的代码弄得一团糟。
2）破窗效应：没修复的破窗，导致更多的窗户被打破。所谓“破窗效应”，是关于环境对人们心理造成暗示性或诱导性影响的一种认识。“破窗效应”理论是指：一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙的被人打破； 一个很干净的地方，人会不好意思丢垃圾，但是一旦地上有垃圾出现之后，人就会毫不犹疑的拋，丝毫不觉羞愧。

技术债务
1）技术债务：开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案，但从长远来看，这种方案会带来更消极的影响，亦即开发团队所欠的债务。
2）总成本 = 开发成本 + 维护成本，维护成本 >> 开发成本