第三章 代码的坏味道
3.1 神秘命名
命名是编程中很难的事情，所以最常用的重构手段就是去改个名字。
如果你发现改名很难，那就说明代码设计有问题。
3.2 重复代码
同一类的两个函数含有相同的表达式，就应该提炼。
3.3 过长函数
活得最长，最好的函数，一般都很短。
如果你觉得需要写注释，大部分情况就代表这个东西需要写进一个独立的函数里面，然后根据用途来命名比较好。
3.4 过长的参数列表
将几个函数共用的参数抽象成类，然后再调用类。
3.5 全局数据
全局数据的问题是，全局数据在任何地方都可以被修改。
所以正确的做法是将全局数据封装起来，用函数将其包起来，这样就知道那些地方修改了它。
3.6 可变数据
核心是缩小作用域。
3.7 发散式变化
如果这个模块，加不同原因的需求的时候，修改的模块都不相同的话，你需要考虑是否要分离出来。比如说你加入redis需要改3个地方，加入mysql需要改4个地方，你就应该抽离出来。
3.8 霰弹式修改
在每次修改的时候，应该只修改一处，而不是到处的修改。如果你说你要加入一个数据库，需要修改3个函数，那么这就需要思考，你是否应该抽离出来。
3.9 依恋情结
模块化，力求代码分出区域，最大化区域内部交互，最小化区域间交互。
如果两个模块交互频繁，你应该合并在一起。
3.10 数据泥团
如果在多个类中，出现了很多相同项的数据，你需要想想是否要抽离出来一个对象。
3.11 基本类型偏执
我们应该创建对象，而不是用一个字符串来写任何东西。
比如有程序员用字符串来表示电话号码，实际上你应该抽象出来一个电话号码对象。
3.12 重复的switch
switch这个东西就不应该存在。
3.13 循环语句
我们应该用管道操作来替代循环，这样能更看清被处理的元素和处理他们的动作。
3.14 冗赘的元素
能简单的代码，尽量简单。未来变复杂的时候，再去考虑它。
3.15 夸夸其谈通用型
同上。
3.16 临时字段
临时的字段不应该存在。
3.17 过长的消息链
如果关系过长，你最好提炼函数。
…… （省略其中的很多点)
3.24 注释
注释是提示你，这个地方该重构啦。
如果你觉得需要写注释的时候，请先重构，试着让所有注释都变得多余。
Original: https://www.cnblogs.com/qscqesze/p/12193564.html
Author: qscqesze
Title: 《重构：改善既有代码的设计》 读书笔记 第三章
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/553156/
转载文章受原作者版权保护。转载请注明原作者出处！