任何一个傻瓜都可以写出计算机可以理解的程式码，唯有写出人类容易理解的程式码，才是优秀的程序员。
——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名哦！
