【软件重构】如何识别代码坏味道

代码坏味道定义：指代码表面的腐化现象，对需求易变性的估计不足、功能重复出现、片段式植入等代码腐化现象。

主要的坏味道分类：

1. 冗余和重复
2. 局部膨胀
3. 耦合结构不良

代码坏味道的层次：

1. 直观层面：一眼看过去就能识别的问题，比如：魔鬼数字、函数/类过长、圈复杂度高、函数/变量命令不规范等一般规范性问题，使用工具门禁都能扫描出来。
2. 微观层面：需要仔细观察才能发现的问题，比如：类字段定义不合理、函数功能不单一、变量作用域过长，需要具体到代码行的具体问题
3. 宏观系统层面：代码架构上的整体问题，如：类职责不单一、上帝类（违反单一原则）、分层不清楚、上下文混乱等，一般是需求本身设计、类定义、类机构设计问题，主要体现在业务与架构的发展问题。

不符合以下四个基本原则中任何一个，即可能存在代码坏味道：

1. 通过所有测试。软件系统对外部需求能够被正确地完成，包括功能性需求和非功能性需求，都能满足用户验收的标准。
2. 最小化重复代码，尽可能消除重复代码。确保软件能够高内聚，低耦合，达到良好正交性的过程
3. 代码表达清晰，优雅。
4. 代码设计的复杂度低，简单明了。

违反以下设计原则-SOLID原则，思考是否存在坏味道：

1.单一职责原则（SRP）

一个对象或者模块应该负责一个职责，如：一个对象应该就只包含单一的职责，并且该职责就完整封装在一个类中。

2.开闭原则（OCP）

一个软件实体应该对拓展开放，对修改关闭。在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被拓展，即在不修改这个模块源代码的前提下改变这个模块的行为。

3.里氏替换原则（LSP,面向对象原则）

派生的子类应该是可替换成基类，也就是说任何基类出现的地方，子类一定可以出现

4.接口隔离原则（ISP，面向对象原则）

类不应该被迫依赖他们不使用的方法，也就是一个接口应该尽可能单一，保持精简的行为

5.依赖倒置原则（DIP,面向对象原则）

高层模块不应该依赖底层模块，他们都应该依赖抽象，抽象不应该依赖细节，细节应该依赖抽象。

总结代码坏味道四种类别：

（1）滥用面向对象

（2）膨胀剂

（3）可有可无

（4）难以修改和耦合