# 代码之丑 ## 1. 命名 ### 不好的命名方法 - 不精准的命名 - 命名过于宽泛，不能精准描述 - 命名要能够描述出这段代码在做的事情。 - 用技术术语命名 - 是一种基于实现细节的命名方式 - 如：xxxMap、xxxSet ### 命名遵循原则 - 🔥描述意图，而非细节。 - 比如，StartTranslation - 面向接口编程，接口是稳定的，实现是易变的 - 技术名词的出现，往往就代表着它缺少了一个应有的模型 - 一个技术类的项目中，这些技术术语其实就是它的业务语言。 - 但对于业务项目，这个说法就必须重新审视了 - 用业务语言写代码 - 建立团队的词汇表 ### 总结 - 好的命名，是体现业务含义的命名 ## 2. 乱用英语 ### 常见的命名规则 - 类名是一个名词，表示一个对象 - 方法名则是一个动词，或者是动宾短语，表示一个动作 ### 几种乱用英语的点 - 违反语法规则的命名； - 不准确的英语词汇； - 英语单词的拼写错误。 ### 如何从实践层面上更好地规避 - 制定代码规范，比如，类名要用名词，函数名要用动词或动宾短语； - 要建立团队的词汇表； - 要经常进行代码评审。 ## 3. 重复代码 ### 重复代码 - 复制粘贴的代码 - 重复的结构 - if 和 else 代码块中的语句高度类似 ### 消灭重复原则 - Don't Repeat Yourself - 每一处都有单一、明确、权威的描述 ### 实践 - 在一个职业的队伍里，谁发现谁修改 - 可以用设计模式和工具框架去解决 ## 4. 长函数 ### 🔥一个好的程序员面对代码库时要有不同尺度的观察能力，看设计时，要能够高屋建瓴，看代码时，要能细致入微。 ### 长函数的产生 - 以性能为由； - 性能优化不应该是写代码的第一考量 - 部分优化交给编译器 - 可维护性比性能优化要优先考虑 - 平铺直叙； - 一次加一点。 ### 消灭长函数的原则 - 定义好长函数的标准：如最长20行 - 做好『分离关键点』 - 坚守『童子军军规』 - 让营地比你来时更干净 ### 重构手法 - 提取函数 ### 一句话 - 把函数写短，越短越好 ## 5. 大类 ### 大类的产生 - 职责不单一 - 字段未分组 ### 所谓的将大类拆解成小类，本质上在做的工作是一个设计工作 ### 软件设计原则 - 单一职责 ### 实践 - 对象健身操 - 聚合层扮演的角色其实一个防腐层，它本身的职责就是和请求应答去做一一应对。一般来说，这样类行为很单一，主要的职责就是数据转换。对于这种类，大一点是可以的，因为它不会对业务造成什么影响。重点在于，这个类里没有业务。 - 重点是，简单的聚合并不是一个好办法，而是需要谨慎地设计通信协议，这才是保证类比较小的根本办法。 ### 一句话 - 把类写小，越小越好。 ## 6. 长参数列表 ### 参数数量多导致的长参数 - 变化频率相同 - 将参数列表封装成一个类 - 一个模型的封装应该是以行为为基础的 - 多个变化频率 - 封装成多个类 - 静态不变 - 成为软件结构的一部分 - 方法：动静分离 - 分离关注点 - 动数据（bookId）和静数据（httpClient 和 processor），是不同的关注点，应该分离开来 - 静态不变的数据完全可以成为这个函数所在类的一个字段，而只将每次变动的东西作为参数传递 ### 标记(flag)参数导致的长参数 - 标记(flag)存在的形式 - 布尔值 - 枚举值 - 直接的字符串或者整数 - 根据标记参数的不同拆分成多个函数 - 重构的手法 - 移除标记参数（Remove Flag Argument） ### 一句话 - 减小参数列表，越小越好。 ## 7. 滥用控制语句 ### 嵌套的代码 - 重构手法 - 以卫语句取代嵌套的条件表达式（Replace Nested Conditional with Guard Clauses） ### 重复的 switch（Repeated Switch） - 重构的手法 - 以多态取代条件表达式（Relace Conditional with Polymorphism） ### 衡量代码复杂度常用的标准 - 圈复杂度（Cyclomatic complexity，简称 CC） - 圈复杂度越高，代码越复杂，理解和维护的成本就越高。 - 工具：Checkstyle ## 8. 缺乏封装 ### 过长的消息链（Message Chains） - 火车残骸（Train Wreck） - 链式调用不一定都是火车残骸。比如 builder 模式，每次调用返回的都是自身，不牵涉到其他对象，不违反迪米特法则。 - 火车残骸的代码和流畅（Fluent）代码的重要差别是，火车残骸描述的具体怎么做，而流畅（Fluent）代码描述的是做什么，是声明式的。 - 重构手法 - 隐藏委托关系（Hide Delegate） - 指导原则 - 迪米特法则（Law of Demeter） - 按照迪米特法则这样写代码，可能让代码里有太多简单封装的方法？不过，这也是单独解决这一个坏味道可能带来的结果。这种代码的出现，根本的问题是缺乏对封装的理解，而一个好的封装是需要基于行为的，所以，如果把视角再提升一个角度，我们应该考虑的问题是类应该提供哪些行为，而非简简单单地把数据换一种形式呈现出来。 ### 以基本类型为模型的坏味道称为基本类型偏执（Primitive Obsession） - 重构手法 - 以对象取代基本类型（Replace Primitive with Object） - 也就是提供一个模型代替原来的基本类型 ### 封装之所以有难度，主要在于它是一个构建模型的过程 - 作为这个类的使用者，你并不需要知道这个类到底是怎么实现的 - 有任何业务上的调整，都会发生在类的内部，只要保证接口行为不变，就不会影响到其它的代码。 ## 9. 可变的数据 ### 可变数据最直白的体现就是各种 setter - 问题 - 相比于读数据，修改是一个更危险的操作 - 比可变的数据更可怕的是，不可控的变化 - 缺乏封装再加上不可控的变化，setter 几乎是排名第一的坏味道 - 重构手法 - 移除设值函数（Remove Setting Method） ### 在实践中，完全消除可变数据是很有挑战的 - 一个实际的做法是，区分类的性质。 - 值对象就要设计成不变类 - 所有的字段只在构造函数中初始化； - 所有的方法都是纯函数； - 如果需要有改变，返回一个新的对象，而不是修改已有字段。 - 实体类则要限制数据变化 ### 函数式编程的本质 - 对于赋值进行了约束 - 很多编程语言都引入了值类型，而让变量成为次优选项 ### 全局数据 - 一个与数据相关的坏味道 ### 一句话 - 限制可变的数据 ## 10. 变量声明与赋值分离 ### 变量的初始化 - 问题 - 先声明后赋值 - 变量初始化与业务处理混在一起 - 基本原则 - 变量一次性完成初始化 - 尽可能使用不变的量 ### 集合初始化 - 问题 - 先声明后添加元素 ### 声明式代码 - 区别 - 命令式的代码 - 告诉你 “怎么做” 的代码 - 声明一个集合，然后添加一个元素，再添加一个元素 - 声明式的代码 - 告诉你 “做什么” 的代码 - 要一个包含了这两个元素的集合 - 总结 - 声明式的代码体现的意图，是更高层面的抽象，把意图和实现分开，从某种意义上来说，也是一种分离关注点 - 用声明式的标准来看代码，是一个发现代码坏味道的重要参考 ### 一句话 - 一次性完成变量的初始化 ## 11. 依赖混乱 ### 缺少防腐层 - 让请求对象传导到业务代码中，造成了业务与外部接口的耦合 - 通过防腐层将外部系统和核心业务隔离开来 ### 依赖倒置原则 - 高层模块不应依赖于低层模块，二者应依赖于抽象。 - High-level modules should not depend on low-level modules. Both should depend on abstractions. - 抽象不应依赖于细节，细节应依赖于抽象。 - Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions. ### 其他 - 习惯于用业务术语去表达，而不仅仅是技术术语。封装是为了概念，而不单纯是为了封装。 ### ArchUnit - 把架构层面的检查做成了单元测试 ### 一句话 - 代码应该向着稳定的方向依赖 ## 12. 不一致的代码 ### 命名中的不一致 - 类似含义的代码应该有一致的名字 - 一旦出现了不一致的名字，通常都表示不同的含义 ### 方案中的不一致 - 应对同一个问题出现了多个解决方案 - 一般是随时间演化造成的 - 随着时间流逝，有新的解决方案了，而原有解决方案虽存在的各种问题，但已深入人心 ### 代码中的不一致 - 不要测私有方法 - 🔥很多程序员纠结的技术问题，其实是一个软件设计问题，不要通过奇技淫巧去解决一个本来不应该被解决的问题。 ### 应对策略 - 团队统一编码风格 - 团队统一编码解决方案 ### 一句话 - 保持代码在各个层面上的一致性 ## 13. 落后的代码风格 ### Java8 Optional - 避免引发空指针问题 - 示例: author?.name ### 函数式编程 - 循环语句是在描述实现细节，而列表转换的写法是在描述做什么，二者的抽象层次不同。 - 列表转换的本身就完全变成了一个声明，这样的写法才是能发挥出列表转换价值的写法。 ### 编程规则 - 声明式编程 ### 一句话 - 不断学习 “新” 的代码风格，不断改善自己的代码