我最近在读《重构：改善既有代码的设计》这本书，马上就看完了。对于重构的思想我是非常认同的，但是对于这些重构手法的落实却有一个疑问。
作者介绍了 60 多种重构手法，每种重构手法都配有非常具体的、标准的、安全的重构步骤。那些重构手法的动机我基本上都能理解，也知道最终代码大概会重构成什么样子，但是那些重构手法的具体步骤我是真的没记住几个。虽然作者自己也说，他平时开发中也不会完全参照这些步骤，只有重构出了问题时，才会按照这些步骤进行。但我还是有几个疑问，想问问大家： 1.大家能记住那些重构手法的具体步骤么，还是说重构多了就会自然而然的记住了？ 2.大家进行重构时，会参照这些具体步骤么，还是按自己的想法来？如果会的话，相似到什么程度呢？ 具体的话还是用 IDE 现成的重构工具, 比如 IDEA 的全套工具, 基本上改名, 提取方法之类的最常用, 其他的多少也会用到, 但是全用到也不太现实.
但是上面有人提到的测试也很重要, 能保证重构的时候即使步子大一点, 也能确保功能没有被破坏掉.
可以找一些讲 TDD 的资料看看, 那里重构应该用的挺多的, 但是可以先不管 TDD, 那个确实还是有点难的
这是我一直对重构的看法……
2. stop over-engineering
停止过度工程
实用代码为主，代码得能跑起来业务
书中的方法论是
在脑子里记录 “坏味道” 与 “重构方法”的对应表，就是改的多了，自己就熟了。
等功能改得差不多了，我再优化下细节，能抽成函数的抽成函数，毕竟 idea 重构功能挺多的
其他的，好像都没怎么用到啊。。
1. 一种是掌握思想就好，目的是如果你想加功能，发现可能需要调整设计，那么可以先重构，让后面的设计可以自然地加进来。
2. 另外一种看法是需要掌握所有的 code smell 和重构方法，目的是如果重构大型项目（我司之前有很多重构遗留代码库的项目）很多时候测试不足或者太烂没法测试，这些重构方法有相当一部分是比较安全的（ IDE 不红，绝大多数情况等价）。所以按照书上背熟可以直接无脑批量重构，即使是代码特别烂或者混淆过全是 ABC，不理解代码不看业务也可能开始重构，在过程中翻来覆去地调整，调整的过程中理解业务和各种坑，最后达到一个不错的状态。Kent Beck 之前还设想搞一个全结构化的编辑器，只允许重构，不允许手敲代码，听起来有点像 Paredit 的 Java 版。
有时候某些持第二种看法的同事会认为第一种看法根本就不是重构，而是重写。这个见仁见智，大家各取所需。
另外重构的核心是发现一个 code smell 开始，消灭一个 code smell 结束，这样的好处：
1. 随时可以停，没时间继续重构就赶紧赶功能
2. 避免漫无目的瞎重构，开始和截止都很清晰
3. 避免一边加功能一边重构，不然 commit 也乱，也经常把功能搞坏
4. 重构完发现还有 code smell 可以继续这个循环消除下一个，一般来说刚开始重构经常可以消灭 code smell，或者以多换少，到后面可能就只能变成一个 code smell 换另外一个，或者更差，这时候就可以考虑结束了。
对于帖子里的“我感觉没有多少人能做到照着作者介绍的步骤去重构的。”
这个其实没那么难，看好了步骤，去 Intellij 里面对号入座，其实 Intellij 的重构功能大多直接照着这本书写的。所以不用记步骤，只用记你需要啥，按个快捷键填空就行了。有的时候需要多步组合起来的重构的可能需要记下，或者用几次就熟了。
对于“不过早的重构”。
一般重构的粒度很小，做每个小功能的时候可以中间可能穿插几个重构循环，一般小的可能就几分钟。做某个功能，最熟悉的时候是比较好的时机，毕竟过一段时间陌生了重构效率反而不高。这个也是作者说“不要告诉经理”的原因，因为这样重构就是开发的一部分，所以没必要专门和他们说了。
对于“这本书太屌了”
这本书比较朴实，不用太捧，跟 CLRS 之类的书不是一个高度的。也有一些缺点，或者这个重构话题本身就不能覆盖的东西。
比如新版的 JS 重构，很多代码风格就有点过时，里面虽然一笔带过函数式编程，但是内容里并没有。重构只能改善已有设计，并不能突破出革命性的设计，所以 React 这种现代设计是不能从旧代码中重构出来的。
还有就是书里面一个缺点是对怎么写测试语焉不详，实践里重构只能用大粒度测试，因为如果你要重构的模块变化，针对这个模块本身的测试重构的时候需要被改的话，这个测试对重构就没意义了（因为你重构的时候正好重写了这个测试你也不知道是不是跟以前一样）。所以一般推荐针对行为和业务的大粒度测试，或者至少比你打算重构的范围要大。