重构改善既有代码的设计——读后感

以下内容均来自——《重构改善既有代码的设计》，说是读后感，倒不如说是经典语录。笔者通读此书，感慨颇多，说是今年来唯一我读起来酣畅淋漓的一本，也毫不为过。通读此书后，笔者在实践中又加以践行——改造了自己的项目，更觉此书字字珠玑。为了抒发理解，我决定写下这篇读后感，但是深感自己表达能力有限，又担心埋没了作者的意思，所以篇中所述，多为作者原话，偶有加工，也停留在语文层面，不违原意，以飨读者。

为什么需要重构，什么是重构

需求的变化，使重构变得必要。

对于软件工程师来说，重构不是额外的工作，它就是编码本身
重构不是重写。
代码被阅读和被修改的次数，远远多于它被编写的次数。
保持代码易读和易修改的关键就是重构
数字时代，软件的名字就是脆弱。
傻瓜都能写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员。

重构的指导方针

重构就是不改变外在行为，而提高代码质量。
先做对，再做好。所谓好，就是更少的坏味道。
刀劈斧砍随性修改，违背了程序精神，不是重构。
重构的意义不是把代码打磨的闪闪发光，而是从经济的角度出发的考量。与客户和经理交流，也要不断强调这一点。

如何操作

大部分重构应该是不起眼的，见机行事的。
大多数重构可以在几分钟——最多几小时——内完成。

一次把名字取好不容易，想到好的就换掉它。
代码越复杂，步子应该越小

如果你要给程序添加一个特性，但发现它缺乏良好的结构而不易修改，那么——先重构这个程序，让他比较容易添加该特性，然后再添加该特性。简而言之，每次要修改时候，首先令修改很容易，然后再进行这次容易的修改！

重构的每个步骤都很简单。
重构必须要有强有力的测试，步子尽可能的小。保证不出错，就是快。
做一次修改，运行一次测试。使用git帮助检索差错和修复问题。二分法定位错误代码，找到那笔提交，分析改掉它。

coding的规范

优美的函数设计是将意图和实现分开。

代码超过六行，就开始散发臭味，不排斥写一行的函数。

函数名的长度不重要
好的变量和函数命名是代码清晰的关键。

性能的担忧

重复一次循环多数情况下对性能忽略不计。在聪明的编译器，现代缓存结束面前，很多直觉是不准确的。
软件的性能通常只与代码的一小部分相关，改变其他的部分，往往对总体性能贡献甚微。

一份结构良好的代码，调优也变得容易。先完成重构，再做性能优化。
短函数不会因为调用而影响性能，反而因为比较容易缓存，能让编译器运转良好。

坏味道总结：

• 复杂的循环
• 超长的函数
• 看不懂的switch
• 大量的注释，预示此处存在坏味道，好的代码注释很少。
• 看不懂调用的静态字段
• 过量的成员变量。
• 不同用处，不断被修改的成员。
  要知道面向函数式编程的一个主题思想就是：

默认情况下，应该尽可能地使用val关键字（类似final 不可变引用）来生命所有的ktolin变量，仅在必要的时候转换成var（可变引用）。 使用不可变引用，不可变对象及无副作用的行数让你的代码更接近函数式编程风格—— 引自 《Kotlin Action》

要知道当前，最流行的现代化语言，非函数式语言莫属。函数式就是潮流，比如电动汽车与燃油车的区别。

实际操作上，一些作者有点忽略的地方：

• as 对重命名的处理仍不算完美，会有出错的可能。
• 永远将函数的返回值命名为result. 我吸纳了这个编程风格
• 同样意思，命名的时候，用短单词代替长单词，用born 代替代替product等。
• 类外，如果是有给的有专门的时间，重构的时候可以根据功能模块重构。这个模块相关的代码一起重构，这样，集中测试会很方便。

更新：2020.05.12
历时七天，我将我的两万行java项目转kotlin项目