Open ymkNK opened 2 years ago
https://lllovol.com/p/2022/2/refactoring-chapter3/
神秘命名 整洁代码最重要的一环就是好的名字，所以我们会深思熟虑如何给函数、模块、变量和类命名，使他们能清晰表面自己的功能和用法。 需要考虑取一个好的名字 重复代码 如果你在一个以上的地点看到相同的代码结构，那么可以肯定：设法将它们合而为一，程序会变得更好。 抽取重复代码，使之能够复用 过长函数 据我们的经验，活得最长、最好的程序，其中的函数都比较短。 短的函数具有更好的阐释力、更易于分享、更多的选择。 函数越长，就越难理解。 每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。 条件表达式和循环常常也是提炼的信号。 可以考虑使用横屏显示器进行开发，这样潜意识里就不会把一个函数写的过长 过长的参数列表 过长的参数列表本身也经常令人迷惑。 如果可以向某个参数发起查询而获得另一个参数的值，那么就可以使用以查询取代参数去掉第二个参数。 使用类可以有效地缩短参数列表。 Go中可以使用struct的方式，来传入较多的参数 全局数据 全局数据是最刺鼻的坏味道之一。 一次又一次，全局数据造成了哪些诡异的bug，而问题的根源却在遥远的别处，想要找到出错的代码难于登天。 良药与毒药的却别在于剂量。有少量的全局数据或许无妨，但数量越多，处理的难度就会指数上升。 尽量少使用全局变量 可变数据 对数据的修改经常导致出乎意料的结果和难以发现的bug。 如果可变数据的值能在其他地方计算出来，这就是一个特别刺鼻的坏味道。 发散式变化 一旦需要修改，我们希望能够跳到系统的某一点进行修改，只在此处进行修改。如果不能做到这一点，你就能嗅出两种紧密相关的刺鼻味道中的一种了。 一个类受多种变化的影响 散弹式修改 如果遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是散弹式修改。 一种变化引发多个类对应改动 依恋情结 所谓模块化，就是力求将代码分出区域，最大化区域内部的交互、最小化跨区域的交互。 如果一个函数跟另一个模块的函数或者数据交流格外频繁，远胜于在自己所处模块内的交流，这就是依恋情结的典型情况。 函数对某个类的兴趣高过对自己所处类的兴趣 数据泥团 你常常可以在很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。 两个类中同样的字段、很多函数签名中同样的參数 这种情况汪汪和历史遗留问题相关 基本类型偏执 大多数编程环境都大量使用基本类型，即整数、浮点数和字符串等。 一个有趣的现象：很多程序员不愿意创建对自己的问题域有用的基本类型。 字符串是这种坏味道的最佳培养皿，比如，电话号码不只是一串字符。 重复的switch 我们现在更关注重复的switch：在不同的地方反复使用同样的switch逻辑（可能是以switch/case语句的形式，也可能是以连续的if/else语句的形式）。应该以多态取代条件表达式消除掉。 例如可以使用策略模式等方式 循环语句 函数作为一等公民以及得到广泛的支持，因此我们可以使用以管道取代循环来让这些老古董退休。 管道操作（如 filter和map）可以帮助我们更快地看清被处理的元素以及他们的动作.
https://lllovol.com/p/2022/2/refactoring-chapter3/
神秘命名 整洁代码最重要的一环就是好的名字，所以我们会深思熟虑如何给函数、模块、变量和类命名，使他们能清晰表面自己的功能和用法。 需要考虑取一个好的名字 重复代码 如果你在一个以上的地点看到相同的代码结构，那么可以肯定：设法将它们合而为一，程序会变得更好。 抽取重复代码，使之能够复用 过长函数 据我们的经验，活得最长、最好的程序，其中的函数都比较短。 短的函数具有更好的阐释力、更易于分享、更多的选择。 函数越长，就越难理解。 每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立函数中，并以其用途（而非实现手法）命名。 条件表达式和循环常常也是提炼的信号。 可以考虑使用横屏显示器进行开发，这样潜意识里就不会把一个函数写的过长 过长的参数列表 过长的参数列表本身也经常令人迷惑。 如果可以向某个参数发起查询而获得另一个参数的值，那么就可以使用以查询取代参数去掉第二个参数。 使用类可以有效地缩短参数列表。 Go中可以使用struct的方式，来传入较多的参数 全局数据 全局数据是最刺鼻的坏味道之一。 一次又一次，全局数据造成了哪些诡异的bug，而问题的根源却在遥远的别处，想要找到出错的代码难于登天。 良药与毒药的却别在于剂量。有少量的全局数据或许无妨，但数量越多，处理的难度就会指数上升。 尽量少使用全局变量 可变数据 对数据的修改经常导致出乎意料的结果和难以发现的bug。 如果可变数据的值能在其他地方计算出来，这就是一个特别刺鼻的坏味道。 发散式变化 一旦需要修改，我们希望能够跳到系统的某一点进行修改，只在此处进行修改。如果不能做到这一点，你就能嗅出两种紧密相关的刺鼻味道中的一种了。 一个类受多种变化的影响 散弹式修改 如果遇到某种变化，你都必须在许多不同的类内做出许多小修改，你所面临的坏味道就是散弹式修改。 一种变化引发多个类对应改动 依恋情结 所谓模块化，就是力求将代码分出区域，最大化区域内部的交互、最小化跨区域的交互。 如果一个函数跟另一个模块的函数或者数据交流格外频繁，远胜于在自己所处模块内的交流，这就是依恋情结的典型情况。 函数对某个类的兴趣高过对自己所处类的兴趣 数据泥团 你常常可以在很多地方看到相同的三四项数据：两个类中相同的字段、许多函数签名中相同的参数。 两个类中同样的字段、很多函数签名中同样的參数 这种情况汪汪和历史遗留问题相关 基本类型偏执 大多数编程环境都大量使用基本类型，即整数、浮点数和字符串等。 一个有趣的现象：很多程序员不愿意创建对自己的问题域有用的基本类型。 字符串是这种坏味道的最佳培养皿，比如，电话号码不只是一串字符。 重复的switch 我们现在更关注重复的switch：在不同的地方反复使用同样的switch逻辑（可能是以switch/case语句的形式，也可能是以连续的if/else语句的形式）。应该以多态取代条件表达式消除掉。 例如可以使用策略模式等方式 循环语句 函数作为一等公民以及得到广泛的支持，因此我们可以使用以管道取代循环来让这些老古董退休。 管道操作（如 filter和map）可以帮助我们更快地看清被处理的元素以及他们的动作.