ToB企服应用市场:ToB评测及商务社交产业平台

标题: 读C#代码整洁之道笔记04_重构C#代码识别代码坏味道 [打印本页]

作者: 美丽的神话 时间: 2023-4-4 14:04
标题: 读C#代码整洁之道笔记04_重构C#代码识别代码坏味道

1. 应用程序级别代码坏味道

1.1. 布尔盲点

1.1.1. 由于函数使用布尔值而导致的信息缺失
1.1.2. 解决方案是将布尔替换为枚举类型

1.2. 组合爆炸

1.2.1. 不同的代码使用不同的参数组合来执行同一件事情的产物
1.2.2. 解决方案使用泛型

1.3. 人为复杂性

1.3.1. 简单的架构复杂化
1.3.2. 解决方案务必保持软件的简单易懂（Keep It Simple，Stupid，KISS）

1.4. 数据泥团

1.4.1. 相同的字段同时出现在不同的类和参数列表中时
1.4.1.1. 说明系统中缺少类定义
1.4.2. 识别并泛化缺失的类可以降低系统的复杂度

1.5. 粉饰注释

1.5.1. 注释中用优美的词句掩盖代码的缺点

1.6. 重复代码

1.6.1. 多次出现的代码
1.6.1.1. bug=技术债务=程序员支出
1.6.2. 解决方案将这些代码添加到当前项目的可重用类并放置在类库中
1.6.3. 解决方案2：面向方面编程（AOP）是另一种删除样板代码的方法

1.7. 意图不明

1.7.1. 他人无法轻易理解代码的意图

1.8. 可变的变量

1.8.1. 不同操作之间多次更改的变量
1.8.2. 消除变量的可变性，使其值更易于预测
1.8.3. 函数编程
1.8.3.1. LINQ

1.9. 怪异的解决方案

1.9.1. 源代码中解决同样问题的方案多种多样
1.9.1.1. 源代码中解决同样问题的方案多种多样
1.9.1.2. 没有制定统一标准而造成
1.9.1.3. 程序员并没有意识到系统中已经存在解决方案
1.9.2. 解决方案：不同的重复的解决方案编写新类，并将最整洁最高效的方式添加到类中
1.9.3. 解决方案2：适配器模式来统一不同的系统接口

1.10. 霰弹式修改

1.10.1. 一种改动需要在多个类中进行修改
1.10.1.1. 复杂的代码还会导致程序员认知负担过重
1.10.2. 减少耦合可以使类更易于测试
1.10.3. 将不属于类的代码移出到恰当的位置可以提高应用程序的可读性、可维护性与可扩展性

1.11. 解决方案蔓延

1.11.1. 一种职责在不同的方法、类甚至库中均被实现
1.11.2. 单一职责转移到同一个类中

1.12. 不可控的副作用

1.12.1. 在产品中由于无法被质量保证过程发现而引起的问题
1.12.2. 唯一的办法就是重构代码使其完全可测，并可以在调试期间查看变量的状态以确保程序的正确性。

2. 类级别代码坏味道

2.1. 过高的圈复杂度

2.1.1. 大量的分支和循环
2.1.2. 1～10
2.1.2.1. 代码简单没有风险
2.1.3. 11～20
2.1.3.1. 较复杂，风险相对较低
2.1.4. 21～50
2.1.4.1. 引起注意，中等风险
2.1.5. 超过50
2.1.5.1. 风险高，必须重构
2.1.6. 解决方案
2.1.6.1. 使用工厂模式替换switch语句
2.1.6.2. 改善if语句条件检测的可读性
2.1.6.3. LINQ语句替换循环

2.2. 发散式变化

2.2.1. 对代码进行一处更改，但是发现自己必须更改许多不相关的方法
2.2.2. 原因
2.2.2.1. 类结构不良造成
2.2.2.2. 复制粘贴代码
2.2.2.3. 利用基类和子类的关系实现继承

2.3. 向下类型转换

2.3.1. 将基类转换为它的一个子类

2.4. 过度的字面量使用

2.4.1. 将字面量保存在常量中
2.4.2. 将字符串字面量放置在本地化资源文件中

2.5. 依恋情结

2.5.1. 当一个方法花费大量的时间处理类中的代码而非自身的代码

2.6. 狎昵（xiá nì）关系

2.6.1. 一个类若依赖另一个类的实现细节
2.6.2. 类之间不应当相互依赖
2.6.3. 类应当是自包含的
2.6.4. 类之间应该尽可能少地互相了解彼此的底细

2.7. 不恰当的暴露

2.7.1. 类暴露了其内部细节
2.7.2. 打破了面向对象编程的封装原则

2.8. 巨大的类

2.8.1. 务必令其尽可能小巧、整洁、易于阅读

2.9. 冗赘类

2.9.1. 一种并不包含什么有效操作的类
2.9.2. 和其他包含相似意图的类合并
2.9.3. 削减继承层次结构
2.9.3.1. 理想的继承层次是1
2.9.4. 非常小的类还可以考虑采用内联的处理方法

2.10. 中间人类

2.10.1. 仅将功能委托给其他对象
2.10.2. 舍弃中间人直接和处理相应职责的类进行交互
2.10.3. 将其与现有类合并

2.11. 孤立的变量和常量类

2.11.1. 使用一个独立的类来定义系统不同部分使用的变量和常量
2.11.2. 丢失其上下文而无法表达任何实际含义
2.11.3. 移动到使用它们的位置

2.12. 基本类型偏执

2.12.1. 使用常量作为字段名称
2.12.2. 不恰当地使用常量保存信息
2.12.3. 使用基本类型值而非使用对象

2.13. 被拒绝的遗赠

2.13.1. 一个类继承自另一个类，却没有使用其所有方法
2.13.2. 考虑是否真的需要基类

2.14. 夸夸其谈未来性

2.14.1. 一个类的功能现在不需要，但是将来可能用到
2.14.2. 死代码，应当将其删除

2.15. 命令，而非询问

2.15.1. 将数据和操作数据的方法绑定在一起
2.15.2. 一个对象包含逻辑，并要求其他包含数据的对象提供数据以供其执行操作，则应当将逻辑与数据合并到一个类中

2.16. 临时字段

2.16.1. 不需要在对象的整个生命周期内存在的成员变量
2.16.2. 将临时字段及操作这些字段的方法移动到它们自己的类中

3. 方法级别的代码坏味道

3.1. 不合群的方法

3.1.1. 一个类中和其他方法截然不同的方法
3.1.2. 考虑该方法的目的
3.1.2.1. 确定哪里才是该方法最合适的落脚点了

3.2. 无用的代码

3.2.1. 现存的方法无人使用
3.2.2. 要识别无用的代码并将其删除
3.2.3. 构造器、属性和变量也应遵循相同的原则

3.3. 过多的返回数据

3.3.1. 远超客户端的调用

3.4. 过长或过短的标识符

3.4.1. 标识符应当既能描述对象又简明扼要

3.5. 过长的代码行

3.5.1. 应尽量将其格式化，在点号和逗号处换行

3.6. 过长的方法

3.6.1. 方法应当只负责执行单一任务

3.7. 参数过多

3.7.1. 方法参数数目超过3个

3.8. 过度耦合的消息链

3.8.1. 当一个方法调用一个对象，继而调用另一个对象
3.8.2. 消息链违反了迪米特法则
3.8.2.1. 类只应当和离其最近的邻居通信
3.8.2.2. 重构类，将所需的状态和行为放在距离其更近的位置

3.9. 过高的圈复杂度

3.10. 人为复杂性

3.11. 依恋情结

3.12. 狎昵关系

3.13. 冗赘方法

3.14. 中间人方法

3.15. 怪异的解决方案

3.16. 夸夸其谈未来性

3.17. 参见前文

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)