任何一个傻瓜都可以写出计算机可以理解的代码，唯有写出人类容易理解的代码，才是优秀的程序员。
——Martin Fowler 《重构》
面对运行缓慢的老系统；前任程序员遗留下乱成一团的代码块；迷宫式的超级大函数……你能怎么办？无外乎两个选择：要么忍，要么重构。
但，重构，是多少人心中的痛！
高手重构代码，是这样的：
而你重构代码，却是这样的：
能力除外，人们抗拒重构的原因还有很多：
项目这么急，能上线就不错了，哪有时间重构？
涉及到的模块太多太杂，重构，风险太大！
重构代码吃力不讨好，还要被同事嫌弃。
互联网行业人员流动这么快，下个月就离职了，重什么构？
……
理由千千万，究其根本，还是对自己的编程技艺的要求不够高。明明知道重构的重要性，却迫于外部环境或形势的压力缴械投降。但是，正如电影《无间道》所说：“出来混，迟早是要还的。”现在不精进自己，练就扎实的重构本领，未来，代码的坏味道定将施以报复。
关于重构，高手这么看
恰逢重构 20 年，软件开发界的不朽经典《重构：改善既有代码的设计》一书做了重磅升级。《重构》一书的作者马丁·福勒（Martin Fowler，世界软件开发大师，全球知名技术咨询公司 ThoughtWorks 首席科学家），在最近的 ThoughtWorks 访谈中，讲到了他对重构的认识及与重构理念相关的种种问题。看看高手如何给你支招。
触发代码重构的原因有哪些？
Martin：需要重构代码的原因当然多种多样。首先，当你无法理解代码时，一个明确的迹象是你花了很长时间想弄清楚一些代码的目的或功能。还有一种情况，借用我个人很喜欢的 Ward Cunningham 的说法：一旦你在脑海中对代码功能有了一定的概念，就要把它从大脑中“拿”出来并放回代码中，这样下次你或其他人再看到这些代码，他们就能真正读懂这些代码。触发重构的另一个因素是开发者想改进代码，但现有代码的架构又令改进难度很大，在这种情况下，重构提升了改进的速度，降低了难度，结构变简单后，改进也就水到渠成了。还是 Kent Beck 那句话说得好：首先让代码架构易于改变，然后再进行简单的改进。
对我而言，下面这些都是触发重构的时机：当你发现代码不够清晰、难以理解时；当你对代码功能有了一些了解，想把这些嵌入代码中时。当你想要改进代码时，比较容易的做法是先进行重构，再添加新功能。
基本上人都有一种倾向：东西没坏就不修，更何况重构。对照“我们重构还不到位”的事实，你认为怎样做才能克服这个障碍？
Martin：我得承认，我不是一个超有说服力的人。我不会努力说服大家改进，我只是尝试解释该如何做事，希望他们自己领悟并尝试最佳实践。谈到不修改代码时，肯定会涉及需要某种代码库来确保修改代码时可以轻松检测到问题，这就是我们非常重视进行严格测试的原因，因为测试是一种很好的监测机制。
还有一些来自项目的技术管理者会向下属说明，改进代码没关系，但只能通过迭代和扩展来写出有效的代码。但是，有时开发者也会固步自封，我就遇到过有些团队的开发者说“哦，我们不该改变”，对上级主管也这样说，而主管会非常诧异，连声说“不对，我真的想重构”。像这种上下级理念完全相反的情况很常见。需要创造一种企业文化，允许大家说：“我们可以回到原点并改进代码。”在测试方面我们有必要的安全基础，这样开发者才能在错误出现时检测到错误。
在开发的过程中，一方面你需要为软件添加新功能，另一方面你也需要重构，以确保软件维持健康状态，否则就无法在软件里继续添加新功能。保持两者的平衡非常重要，这要求开发者有良好的判断力。像许多事情一样，良好的判断力确实是个关键元素，但遗憾的是，并没有什么捷径来传授判断力。
商界人士常常认为：如果程序没坏而且没有添加新功能，就不该浪费时间改进。你如何认识重构的意义？
Martin：雇主花钱雇我们做好技术工作，而且这其中很大一部分就是使代码库保持健康状态，这样未来就能在代码库上持续添加新功能。如果不重构，严格来说我们就辜负了雇主的期望，因为不重构会导致功能开发速度变慢。从经济角度来看，我们有责任让代码库稳定处于健康状态，重构当然是一种使关键代码库保持健康状态的重要方法，如果不能令代码库保持在健康状态，就相当于我们从客户和上司那里“偷”钱。因此，从根本上说，我们有责任进行重构。
在我看来，你永远不该用诸如“这是我们的职业责任”“这是正确的事情”或 “出于道义理由”等话术，我知道很多人都喜欢用这套说法，而当你滥用术语时，你已经迷失了。重构的唯一原因是经济原因，重构的目的是更快地增加更多功能，以便更及时地响应各方需求的变化，而经济原因才是重构的底层原因。顺便说一句：这也是明智的专业态度才是正途的原因，因为老板花钱请开发人员用代码快速生成功能，我们也该站在这个立场上考虑重构问题。但严格来说，对管理者或企业而言，快速开发或新增功能，或者使代码库保持健康等因素并不重要。他们付钱给开发人员搞软件开发正是为了处理这些问题。
重构思维是否可以超越代码，应用到其他层面？
Martin：绝对可以。重构的关键是理念：如何进行最细微的改变，而不是努力搞大的变化尝试，并弄清楚如何做到这一点。通过重构就会发生很多细小的变化，然后将这些变化串联起来，这就是重构思维适用于这种情况的核心。我们如何将一个大变化拆分为许多小变化，又在尽可能多进行细微变化的同时，不改变系统的整体表现，然后随时间推移，反复练习并思考如何进行拆分。我书中的内容就是我通过重构框架思考问题的体验，尝试各种重构手法并做出决定。书里有一整套机制让我能够高效地进行重构，但主要时通过实践进行重构。你尝试了不同的重构手法，然后找出哪个重构手法能生成理想序列，你尝试识别出这种重构手法，同样的逻辑也适用于更广泛的层面。
高手重“道”，Martin 的分享更多是从认知上告诉你，软件大师或者一个高级开发人员是如何看待“重构”这件事的。那么，如何修炼自己重构的功力？这就不得不向大家推荐《重构（第 2 版）》这本不朽经典的升级秘笈！
备受关注的《重构（第 2 版）》在第 1 版的基础上做了全面修订，反映了编程领域业已发生的许多变化。第 2 版中介绍的重构列表更加内聚，并用 JavaScript 语言重写了代码范例。此外，第 2 版中还新增了与函数式编程相关的重构范例，旨在教会读者如何在没有类的环境下开展重构。新版沿袭了第 1 版的结构，依次解释什么是重构，为什么要重构，如何通过“坏味道”识别出需要重构的代码，以及如何在实践中用任何编程语言都可以成功实施重构。
很多人关注到新版中代码示例的使用从 Java 变成了 JavaScript。Martin 解释道：重构背后的理念和架构适用于任何编程语言。我选择 JavaScript，只是因为我觉得它是一种应用广泛的语言。无论你使用哪种语言编程，基本机制都是完全相同的，语言与语言之间固然存在差异，但我认为语言之间的共通之处远比差异多。要知道，Java 是一种非常严格的面向对象编程语言，第 1 版中所有的重构都是基于面向对象的。我想通过再版来说明你可以用任何（编程）语言、在任何环境中、遵循书中提到的范例进行重构，这是我计划再版这本书的另一个理由，也是我再版这本书的源动力。如果这次内容更新得非常到位，可以说再过 20 年我都不用再修订这本书了。
坏味道、测试先行、行为保持的变更动作，是重构的基本功。在《重构（第 2 版）》里，重构手法的细节被再度打磨，重构过程比之第 1 版愈发流畅。细细品味重构手法中的前后步骤，琢磨作者是如何做到行为保持，这是能启发读者举一反三的读书法。举保持对象完整重构手法为例，第 1 版中的做法是在原本函数上新添参数；而第 2 版的做法则是先新建一个空函数，在其中做完想要的调整之后，再整体替换原本函数。两相对比，无疑是新的做法更加可控、出错时测试失败的范围更小。
对比前后两版的重构列表，你会发现：第 2 版收录的重构手法在用途上更加内聚，在操作上更加连贯，更重视重构手法之间的组合运用。第 1 版中占了整章篇幅的“大型重构”，在第 2 版中全数删去。一些较为复杂的重构手法，例如复制“被监视数据”、塑造模板函数等，第 2 版也不再收录。而第 2 版中新增的重构手法，则多是提炼变量、移动语句、拆分循环、拆分变量这样更加细致而微的操作。这些新增的手法看似简单，但直指大规模遗留代码中最常见的重构难点，正好补上了第 1 版中阙漏的细节。这一变化，正反映出 Martin Fowler 对于重构一事一贯的态度：千里之行积于跬步，越是面对复杂多变的外部环境，越是要做好基本功、迈出扎实步。
修炼秘笈在此，最重要的还是上手实践。重构就像软件开发的大多数工作一样：除了动手做，别无他法。《重构》这本书肯定能帮助那些初次接触重构概念的人，但它也能帮助那些了解重构的人分享相关技能。Martin 也提醒读者：请记住重构的要义就是小步骤改进，确保你频繁提交。如果出了什么问题，你只需回滚到先前的提交记录上，这就会降低重构的压力。重构肯定不会给你带来太坏的影响，因为大不了你就回滚呗，这就是版本控制系统的用途。所以，赶紧上手重构吧，操作才是关键。
那么看完上面的内容，你是不是对《重构 改善既有代码的设计 第2版 平装》心动了呢，心动不如行动哦~
读者分享：现在可以免费把这本书送给有需要的小伙伴哦！！！
您只需要关注我后分享这篇文章，然后加入我的Qqun :688298281 即可找管理获取！限前30名哦！
