工作几年你就会发现一年又一年，代码你会更嫌弃之前写的，这大概就是你感觉你自己优化自己，或者你觉得别人写的代码你会有强迫症的想要改的舒服点（代码洁癖）。
那么代码优化是每个码农该有的素养，久而久之，每个人都会有自己的代码风格，关键代码是大家读的舒服，读的懂才是好代码，那今天简单说说代码优化。
有人说，有很多人说，代码优化是一把双刃剑。
有时候为了优化或者在错误的原因下优化你的代码，可能会造成错误的方向和结果。
现实工作当中，我们是为了生产一个可用能用的软件，而不是漂亮的代码。而整理代码是件花费时间和成本的事情，在能保证工作完成的情况下，可以优化你的代码，提高你的代码可读性和复用性。
但是对于有些紧急开发的项目，大可不必花很多时间在优化代码上，并不是不优化性能，两码事。
所以我个人觉得代码大部分不适合优化。
那么什么场景下适合
1、霰弹式的修改
遇到某种变化，需要修改多处不同地方代码
例子举的不是很好，可以大概很容易懂
public static int add(int a, int b){
int c = a + b;
return c;
}
public static void change(int a, int b){
int a = a + b;
}
public static void main(String[] args){
int a = 1;
int b = 2;
change(a,b);
int c = add(a,b);
}
//修改
public static int add(int a, int b){
int c = a + b;
return c;
}
public static void change(int a, int b){
add(a,b);
}
public static void main(String[] args){
int a = 1;
int b = 2;
change(a,b);
int c = add(a,b);
}
这样只要修改add方法就可以做到统一了。
2、重复的代码
同一个类含有两个相同的函数表达式
3、函数过长、过长参数、过大的类
建议一个方法不要太多处理逻辑，尽量保证一个方法一个用处，比如加减乘除运算，分成4个方法，不要集成在一个方法运算。
4、Divergent Change（发散式变化）
如果某个类经常因为不同的原因在不同的方向发生变化，比如：你要新增一个数据库，我们必须修改这三个函数。而更好的方式是，每来一个对象或者只因一个变化而改变。这有点避免霰弹式的行为。
5、平行继承体系
如果你发现为某个类增加一个子类的时候，也必须为另一个类添加相同子类
解决该问题一般策略：让一个继承体系的实例引用另一个继承体系的实例
6、夸夸其谈的未来性
不要因为未来有可能要用就写上，不用就丢弃
7、过度耦合的消息链
用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象。。。这就是消息链
8、数据泥团
有时候几个类中有相同的参数和字段，这些总是绑在一起，看似可以整合，但是又好像有所差别。
那么最好的评判标准就是删掉众多数据中的一项，如果这么做，其他数据有没有因而失去意义？如果他们不再有意义，那么你应该为他们产生一个新对象。
参考：《重构-改善既有代码的设计》