《重构》-代码的坏味道-1

每次在接手迭代的项目的时候或者是在与同事合作的时候，都会吐槽谁谁的代码垃圾，写的看不懂，没有办法下手去修改，或者是牵一发动全身，代码的所表达的模糊。但是我们自己写的时候有时候根本不知道代码所带来的恶劣后果。代码的坏味道就要即使嗅到更正。

命名

清晰严格的命名，就不会多思考函数本身的内部逻辑，可以从命名的角度来看函数、变量、类的作用，不用再去打谍战片。

重复代码

出现重复代码就是程序设计有问题，不能复用，导致后期维护困难等一系列问题

过长的函数

开始工作的时候，每次写代码都会写到一个函数中去，导致后面找问题，自己都不愿意去看自己的代码。阿里巴巴的静态扫描插件中也会建议代码不超过80行，阅读困难，处理不同功能的模块放到一个函数中，会让人产生歧义。对于主函数而言，只关注处理逻辑本身，不关心具体怎么做，这时候就要封装函数了，让做某一件事的代码块去提出新的函数，尽量简化每个函数之前的参数的传递，让函数看起来清晰明了。

过长的参数列表

函数的参数传递，如果传入过多的参数，会造成代码的阅读性困难，参数传递过程中所起到的参数在子函数中的影响也会变得不可控，因此我们应该尽可能少的传递参数，如果参数过多就应该以对象为参数传递。

可变的数据

对数据的修改可能会造成难以理解bug，Java是地址传递的，在这一块尤为重要，我们应该在引入参数的时候，备份数据，用新的参数接收，然后在做处理。减少变量的作用域。

发散式的变化

这种其实我们很容易忽略的，我们希望把某个变化值控制在一个点，如果我们希望去修改某个逻辑，那么只需要修改这一处就行了，如果一段逻辑我们需要去修改3个函数，这样会有可能导致修改不到位。控制在一处我们就不需要去关心上下文的理解，只需要关注这块代码的逻辑，改一次就了。

散弹式修改

这种和发散式变化类似，但是又不同，如果每次修改，都需要将函数中不同地方进行小修改。比如增加字段会导致不同类都会去增加字段，这样很容易遗漏某个类。这种情况需要增加类的内联，或者函数的内类，修改函数把相同类型的分散的逻辑统一到同一部分中

依恋情结

所谓模块化，就是力求将代码分出区域，最大化区域内部的交互，减少跨模块的交流。但是如果代码的模块与模块之间的数据交流远胜于代码块内部的交流，就会出现依恋情结，模块之间的耦合度高。这时候我们就需要再次提炼函数，把依恋的部门转移出去，使其中一个函数承受这部分。原则是将总是变化东西放一块，数据和引用这些数据的行为总是一起变化的。

数据泥团

在数据项中，我们有时候会看到很多相同字段，相同含义的参数出现，这些字段都往往会拥有自己的对象，这时候我们一会儿取这个对象的参数，一会儿取那个对象的参数，虽然可能对象的值一致。这会造成阅读困难和理解困难，有时候还会造成难以察觉的bug，这时候就需要瘦身，或者新建一个类来消除这些数据隐患。