大家好，又见面了，我是全栈君。
本篇文章的内容来自《重构 改善既有代码的设计》一书学习笔记整理并且加上自己的浅显的思考总结！
知道重构的原则和何时进行重构，那本篇就总结一些代码的坏味道，知道具体从哪些方面来进行重构。
kent Beck提出用 味道来形容重构的时机。
作者说：何时必须重构没有一个精确的衡量标准，任何量度规矩也比不上一个见识广博者的直觉。如果没有广博的见识，也可以通过一些迹象来发现这里有一个可以用重构来解决的问题。
在不断的学习和成长中，我们必须要学会 培养自己的判断力和“嗅出代码坏味道”的本领。
下面会列出一些“坏味道的条款”，愿他们能够为你指引正确的方向。
代码坏味道
1、 重复代码（Duplicated Code）
坏味道行列中 “带头大哥” 就是 重复代码。如果在一个以上的地方/看到相同的程序结构，那么可以肯定 ： 设法将他们合二为一，程序会变得更好。
最单纯代码重复 是 同一个类的两个函数有相同的表达式。 说白一点就是两段代码一模一样。 此时可以采用 **提取方法（Extract Method）**的方法提炼重复的代码。 在其他地方统一的调用提炼出来的那一段代码。【现在IDEA这个工具有代码重复检查功能，如果两段代码重复会给出提示，如果在开发遇到重复提示，不要绕过去，视而不见。我认为应该想着看如何去优化】
另一种常见的情况： 两个互为兄弟的子类内含相同表达式。这种情况下也可以使用 提取方法（Extract Method），将提炼出的代码推到 超类内。
【不管什么方式的代码重复。最主要的是进行提炼，确保重复的代码只有一套】
2、过长函数（Long Method）
拥有短函数的对象会活得比较好，比较长。不熟悉面向对象中，常常觉得对象程序有无穷无尽的委托，根本没有进行任何计算。接触时间长后，你就会发现这些小小函数有多大的价值。
“间接层” 所能带来的全部利益—解释能力、共享能力、选择能力，都是小型函数支持的。
程序越长越难理解，这已经成为程序员的共识。
在当前的实际开发中，你应该更积极地分解函数，并且给分解好的小函数起一个好名字，让第二阅读者可以直接通过函数名字能够知道函数的作用，而不必去看其写了什么。
在很多场合中，把函数变小只需要只用提取方法（Extract Method），找到函数中集合在一起的部分，提炼一个新函数。
如何去确定该提炼哪一段代码呢？一个很好的技巧是： 寻找注释。 它们通常能指出 代码用途和实现手法之间的语义距离。条件表达式和循环常常也是提炼的信号。
【一般尽量一个函数的代码函数控制在几十行内，太长了就要想着进行拆分】
3、过大的类（Large Class）
如果想利用单个类做太多的事情，就往往会出现太多的实例变量。 一旦如此，重复代码 也就接踵而至了。
【在项目中见到过，在实体类中写了大量的业务代码，看起来真是痛苦！】
4、过长参数列（Long Parameter List）
刚开始学习编程的时候，老师教过：把所有的函数所需要的东西都以参数传递过去。
【但是所有的东西都是一个balance，过度了就不好了】
太长的参数列难以理解，并且很多时候会造成参数前后传递不一致，不易使用，而且一旦你需要添加或者删除参数，那么整个方法就不得不进行修改。这样代码在维护起来也不少很方便。
所以如果在代码中遇到过长的参数传递，一定要进行优化和重构。
【我这边建议是如果是参数传递较多，一个是可以使用Map进行封装，二是定义对象进行参数传递。】
5、发散式变化（Divergent Change）
如果某个类经常因为不同的原因在不同的方向上发生变化， 发散式变化就出现了。当你看着一个类说： 如果新加入一个数据库，我必须要修改 这三个函数；如果新出现一个金融工具，我必修这四个函数。 那么此时也许将这个对象分成两个会更好，这样一来每个对象就可以只因一种变化而需要修改。
【这种味道很难嗅出来，不过一旦有类似味道，就要注意了】
6、散弹式修改（Shotgun Surgery）
当遇到某种变化，你都必须在许多不同的类内做出需要小修改。 散弹式修改： 一种变化引发多个类相应修改。
【举个简单的例子：】如下伪代码
// state : 1 开启 ，0 关闭
Class1{
if(state == 1){
// do something
}
}
Class2{
if(state == 1){
// do something
}
}
想类似代码，如果状态state的标识修改了，那么涉及的代码都要做更改
7、依恋情结（Feature Envy）
对象技术的全部要点在于：这是一种“将数据和数据的操作行为包装在一起”的技术。
有一种经典的气味：函数对某个类的兴趣高过自己所处类的兴趣。
疗法：把这个函数移到另一个地方，移动到它该去的地方。先使用 提炼函数（Extract Method） ，在使用 移动函数（Move Method）。
这种依赖并非所有的情况都是这么简单。一个函数往往会用到几个类的功能，那么它究竟该被置身何处？
原则：判断哪个类拥有最多此函数使用的数据，然后就把这个函数和那些数据摆放在一起、
【这种功力还是需要锻炼，有时候没有那么直接可以一眼看出】
8、Swtich 现身（Switch Statements）
面向对象程序一个最明显的特征就是：少用swtich（或case）语句。
从本质上说：switch 语句问题在于重复。
解决： 可以使用多态来优雅解决此问题。（如可以参考案例1中的代码）
总结
代码的坏味道书中列举了很多，先就总结上面这么多，也是一些平时在写代码经常会遇到的。
如果想了解更多推荐你阅读书籍。
有时候少就是多，每天不要强求掌握太多，相信积累的力量。 重构是一条要走很长的路，掌握重构思想，精进代码质量！
如果您觉得这篇博文对你有帮助，请点赞或者喜欢，让更多的人看到，谢谢！
如果帅气（美丽）、睿智（聪颖），和我一样简单善良的你看到本篇博文中存在问题，请指出，我虚心接受你让我成长的批评，谢谢阅读！
祝你今天开心愉快！
欢迎访问我的csdn博客和关注的个人微信公众号！
愿你我在人生的路上能都变成最好的自己，能够成为一个独挡一面的人。
![【《重构 改善既有代码的设计》学习笔记3】代码的坏味道[通俗易懂]](http://qn.javajgs.com/20220224/34c242f8-d305-4bc1-8e25-2a63edaadf682022022436e2ee2d-6a0e-4906-aa59-edb9170dcba71.jpg)
![【《重构 改善既有代码的设计》学习笔记3】代码的坏味道[通俗易懂]](https://javaforall.net/wp-content/uploads/2020/11/2020110817443450.jpg)
不管做什么，只要坚持下去就会看到不一样！在路上，不卑不亢!
博客首页 : http://blog.csdn.net/u010648555
© 每天都在变得更好的阿飞
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/121052.html原文链接：https://javaforall.net
