对于重构有几个疑问，希望能过来人能解答一下！

[mitu9527]

我最近在读《重构：改善既有代码的设计》这本书，马上就看完了。对于重构的思想我是非常认同的，但是对于这些重构手法的落实却有一个疑问。

作者介绍了 60 多种重构手法，每种重构手法都配有非常具体的、标准的、安全的重构步骤。那些重构手法的动机我基本上都能理解，也知道最终代码大概会重构成什么样子，但是那些重构手法的具体步骤我是真的没记住几个。虽然作者自己也说，他平时开发中也不会完全参照这些步骤，只有重构出了问题时，才会按照这些步骤进行。但我还是有几个疑问，想问问大家：

1.大家能记住那些重构手法的具体步骤么，还是说重构多了就会自然而然的记住了？
2.大家进行重构时，会参照这些具体步骤么，还是按自己的想法来？如果会的话，相似到什么程度呢？

[evilic]

不过早的重构。

这是我一直对重构的看法……

[sumarker]

《重构》这本书据说很厉害，所以买了，但是一直没看。
关于重构，其实我蛮同意楼上等观点
@evilic 经历过的几个公司也都是 “项目出现了一些问题才考虑重构的”
一方面是考虑到成本（时间 /人工）
另一方面也是考虑到，代码可能已经经历了不知多少人到修改，一些历史功能连文献都缺失了，重构可能会导致现在已经上线运行都项目不可用。
所以，宁愿选择“重写” 也不去“重构”

[dany813]

重构的前提是知道以前的逻辑，接受老项目不知道逻辑的，想重构，不如重写

[mitu9527]

@evilic 当然，如果代码工作的好好的，而需求又没变化，当然不需要重构。不过现实中，更常见的是重构不足甚至是从来没有重构，重构过多还是比较少见的。

[mitu9527]

@sumarker 不是我炫技哈，从你留言里面的一些回复来看，你确实还不了解重构。你可以先去看一下《重构》的第二章，希望能帮到你。

[mitu9527]

@dany813 那要看老项目的质量如何了，如果能满足重构的前置条件，就可以重构。当然，现实中确实大多数项目做得都乱七八糟，连测试都砍掉了，当然也就不能进行重构了。

[taaaang]

步骤只是让你有一个清晰的思路，如果你对代码足够熟悉，你的编码能力足够好，直接跳过细节到结果也当然是可以的。自信点，老弟。

[mitu9527]

@taaaang 因为刚看完重构，还没实践过，所以没信心，担心就我自己是这样。听你这么一说就放心了，谢了！

[liununu]

重构是可以随时进行和停止的。
大型重构想要一步到位太难了，想套书里的手法也是比较麻烦的，可以先解决一些简单的 Code Smell，一步步来化简问题。

[312ybj]

目前正在重构同事的代码， 主要是更改逻辑，优化速度， 还有不规范的语法。
感觉就是这个代码健壮性太低，可读性太低， 问题客户要抓紧要，不能自己重写，只能重构。
这本书我只看了一点， 主要是改代码的时间居多，
我现在的做法是：
1. 不改变原有功能完整性
不改变软件可观察行为的前提下改善其内部结构
首先保持代码功能的有效性
确保代码功能没有变化的情况下再进行重构

2. stop over-engineering
停止过度工程
实用代码为主，代码得能跑起来业务

书中的方法论是
在脑子里记录 “坏味道” 与 “重构方法”的对应表，就是改的多了，自己就熟了。
等功能改得差不多了，我再优化下细节，能抽成函数的抽成函数，毕竟 idea 重构功能挺多的

[jones2000]

重构最最重要的 1 件事就是要写单元测试， 否则你重构的越多，可能出现 bug 的机率也最大， 如果你们老板给你们的配置是 1 个开发配 2 个外包的自动化测试的人员，那这个重构是轻松的。 否则要很小心， 可能会把好的功能改坏了。尤其的底层的重构，这些模块可能其他业务部门也用了。 如果没有完整的单元测试和整体的功能测试，就算改完了， 上线都是提心吊胆的。

[javaWeber]

我就只是把超过 100 行的方法抽取成多个方法，方法参数太多的就抽取成对象，然后把类的变量名改成好理解的。

其他的，好像都没怎么用到啊。。

[johnsona]

@wu67 小黄鸭调试法

[namelosw]

这本书是之前同事翻译的，我司常年聊这种话题，也做过挺多培训，还做过很多重构的项目。其实有两种不同的看法都有：

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 这种现代设计是不能从旧代码中重构出来的。

还有就是书里面一个缺点是对怎么写测试语焉不详，实践里重构只能用大粒度测试，因为如果你要重构的模块变化，针对这个模块本身的测试重构的时候需要被改的话，这个测试对重构就没意义了（因为你重构的时候正好重写了这个测试你也不知道是不是跟以前一样）。所以一般推荐针对行为和业务的大粒度测试，或者至少比你打算重构的范围要大。

[mitu9527]

@namelosw 受教了，谢谢！