重构20年，有人说Martin Fowler改变了人类开发软件的模式，这一点也不过分，从《分析模式》《UML精粹》《领域特定语言》，到这本《重构》新版可以看得出来，他的每一本书都是软件开发人员必备的案头读物。此前他参与的“敏捷宣言”，更是引领了整个行业对敏捷开发的认识，一直到现在。
2009年，熊节在为《重构》第1版的中译本再版整理译稿时，他已经隐约察觉行业中对“重构”这个概念的矛盾张力。
如今又是10年过去，只从国内的情况而论，“重构”概念的表里分离，大有愈演愈烈之势。随着当年的一线技术人员纷纷走上领导岗位，他们乐于将“重构”这块漂亮招牌用在更宽泛的环境下，例如系统架构乃至组织结构，都可以“重构”一下。然而基本功的欠缺，却也一路如影随形。当年在对象中的刀劈斧砍，如今被照搬到了架构、组织的调整。于是“重构”的痛苦回忆又一遍遍重演，甚而程度更深、影响更广、为害更烈。
此时转头看Martin Fowler时隔将近廿载后终于付梓的《重构》第2版，熊节说：“我不禁感叹于Fowler先生对‘微末功夫’ 的执着。在此书尚未成型之前，我和当时ThoughtWorks的同事曾有很多猜测，猜Fowler先生是否会在第2版中拔高层次，多谈谈设计乃至架构级别的重构手法，甚或跟随‘敏捷组织’ ‘精益企业’的风潮谈谈组织重构，也未为不可。孰料成书令我们跌破眼镜，Fowler先生不仅没有拔高，反而把工夫做得更扎实了。”
今天小编非常有幸邀请到了《重构》 (第2版）译者熊节老师，来听听他的所思所想。
熊节
在IT行业已经打拼了18年，在金融、零售、政府、电信、制造业等行业的信息化建设方面有着丰富经验，是中国IT业敏捷浪潮的领军人物。熊节拥有利物浦大学MBA学位。
异步社区：熊老师已经是异步的老朋友了，目前在做哪些项目，可以聊聊吗？
熊节：我去年离开了效力十几年的ThoughtWorks，加入了宝尊电商，目前在分管宝尊电商的成都研发中心。敏捷的思想正在不断下沉到大量的国内企业，宝尊的IT也在进行着敏捷的转型。用敏捷思想帮助国内企业提升响应变化的能力，从过去到现在一直是我关注的问题。
异步社区：时隔20年再次翻译《重构（第2版）》一书，是什么感觉？心态有很大的转变吗？为什么？
熊节：可以说有转变，也可以说变化不大。2008年《重构（第1版）》再版加印的时候，我有一个观察：国内真正采用重构技术的团队和个人，其实比例很小。虽然这本书有好几十万甚至上百万的读者，但更多的读者是叶公好龙。这个观察，到今天其实变化也不大，大部分团队和个人仍然处在没有测试、没有持续集成、不敢也不能重构的状态。对这种情况，我的悲观态度比起2008年来也没有什么改变。
不过在这十多年里，我也看到一些团队、一些个人真的从《重构（第1版）》中学到了东西，践行了其中的思想和实践，并且收到了好的效果。于是我的心态又增加了乐观的一面，我会想再多做一些重构的普及工作，多影响一些人学到好的编程方式。例如第2版的另一位译者林从羽，虽然很年轻，但是受重构思想的影响很深，也很坚定地在践行。这样的年轻人让我感到，做这样的普及工作还是有意义的。虽然对整个行业的影响微乎其微，至少可以影响到一些人。
异步社区：重构思想在国内发展史是怎样的？可以分享一些细节吗？
熊节：2001年12月的《程序员》杂志用十多页的篇幅介绍重构，这是国内的出版物首次介绍这个技术，当时负责这些内容的技术编辑就是我。后来随着极限编程丛书、《敏捷软件开发》的出版，2003年由我和侯捷老师翻译的《重构》出版时，我当时认为敏捷、极限编程、重构的理论基础已经齐备了，国内的行业应该很快能采纳这些新的技术、新的方法。
然而事实证明我太乐观了。当时的中国IT大环境，对高质量、响应变化没有太高的要求，整个行业都满足于不做自动化测试、没有持续集成的很原始的工作方式，重构的土壤是不存在的。到2008年，对重构感兴趣的团队和个人并不多。这可能也是当时机械工业出版社没有续签《重构（第1版）》版权、人民邮电出版社接手再版的原因。
2008年以后，随着互联网浪潮的到来，以及通信行业大规模向敏捷转型，重构（和其他敏捷实践一起）开始真正受到了重视，《重构》这本书也开始成为很多程序员的案头书。但是说实话，重构及其对单元测试的要求，对于一般的团队和个人来说，难度太大了。2010年以后，国内的敏捷浪潮开始转向Scrum，重管理实践、轻技术实践，很多团队和个人也就心安理得地把重构束之高阁了。
异步社区：本书作者Martin Fowler曾说“任何一个傻瓜都能写出计算机可以理解的代码。唯有能写出人类容易理解的代码的，才是优秀的程序员。”您认同吗？为什么？
熊节：100%认同。
关于“编程到底是个什么活动”这件事，我跟很多人有分歧。很多人认为编程是个科技活动，但是我始终认为，以调用API和简单的循环、条件逻辑为主，大多数日子里四则运算都用不全（主要是除法不怎么用——多谢郑晔的梗），这样的工作硬要说它是个科技活动，我觉得很牵强。
我一直认为，编程其实是个社会活动。一方面，程序员要把自然语言说出来的需求翻译成机器能运行的机器语言；另一方面，翻译出来的结果（也就是代码）还要支撑团队（包括技术和非技术的团队）不断地在它基础上协作和交流。前者（即“翻译”这一步）是很基础也很简单的，用郑晔的话来说，“四则运算都用不全”，也就是传说中找个高中生来培训几天就能干的活。然而实践证明，找个高中生来培训几天，是做不好软件的。问题出在哪儿，就因为编程的大挑战不是把代码写出来，而是要在代码的基础上建立有效的多方沟通。
当然，话不能说得太死。有没有真正属于科技活动的、把代码写出来本身就很困难的编程任务呢？是有的。但大部分（我保守点说吧，90%以上）程序员日常面对的是不是这样的任务呢？我觉得不是。90%的程序员在90%的时间面对的任务，还是四则运算都用不全的、以沟通和翻译为主的任务。我们应该谦卑地认识到这一点，并且诚恳地采纳能把这种任务做好的工作方式。
异步社区：有人说“重构代表了一种观点，是解决问题的一种方法论，是每个程序员写代码的必备技能”，您怎么看待？
熊节：一方面是我前面说的，大部分人在大部分时候处理的编程任务，本质上是个沟通活动，那么沟通就会有沟通不畅的情况，需要不断调整自己的沟通方式，找到好的沟通方式，让沟通的另一方（可能是业务的代表，可能是以后维护代码的人，可能是使用API的人，等等）能更好地理解。
另一方面，现在大家都在说这个时代是“VUCA”（易变、不确定、复杂、模糊）的，都在说要拥抱变化。那么到底要怎么拥抱变化，很自然的答案就是要降低变化的成本，不能每次要修改就造成破坏。怎么能修改而又不造成破坏呢？第一是要有测试，第二是要有靠谱的修改方法，这两点恰恰就是重构的思想。所以我完全赞同，每个程序员都需要掌握重构的技能，否则他/她的工作方式就会跟不上时代的要求。
异步社区：《重构 第2版》与第一版相比有哪些变化？这本书您最想推荐给谁看？
熊节：很多人说，《重构》第二版跟第一版相比最大的变化是举例所用的编程语言从Java变成了Javascript。但其实这不是一个非常重要的变化。作者展示的重构手法在各种主流的面向对象语言中基本上都可以通用，并且也没有太特别的Javascript语言特性。
在我看来，第二版最大的变化是变得更加务实了。这种务实感体现在几个方面：
第一是增加了一些颗粒度更小的重构手法；
第二重构的做法有所改进，更加注重行为保持；
第三是删去了第一版最后对“大规模重构”的介绍。
我觉得，Martin Fowler这种脚踏实地的态度是很值得钦佩的。我们这个行业里，有太多高举高打的浮夸，缺的是脚踏实地做好一件件小事的工匠精神。
我认为所有程序员都应该读《重构》，应该把坏味道列表背下来。缺乏这个基本知识，就无从谈论代码坏在哪里，更无从说改进了。
异步社区：您曾说：“我已经隐约察觉行业中对“重构”这个概念的矛盾张力”为什么这样说？
熊节：就是我前面说的叶公好龙的问题。所有人都喜欢说“重构”这个概念，但是很少人真的花精力把重构的基本功练扎实。这也折射我们这个行业的现实情况，吹漂亮话的人多，沉下心把一招一式练扎实的人少。
异步社区：您认为国内做的最好的重构案例是哪个？为什么？
熊节：我不知道这样的案例。
我有次跟朋友说到，重构是一个悖论：会重构的人，会把测试做到位，把持续集成搭建好，随时留意坏味道，随时重构，所以他根本不需要跟人说他在重构。跟人大张旗鼓讲重构、甚至把重构变成一个“案例”的，基本上可以肯定，他不会重构，他在打着“重构”的大旗瞎搞。
异步社区：在ThoughtWorks工作的经历给您最大的收获是什么？
熊节：最大的收获大概就是见到了、经历了很多不同行业、不同类型的软件系统和项目，然后明白了一个道理：软件都是一样的，写好代码的方法都是一样的。很多人会说“我们这个行业很特殊你这套方法搁我们这儿都不适用”，我在十多个不同的行业里每次都听人这么说，听多了就明白，这些都是扯淡，都是懒人给自己找借口。
异步社区：从2010年《重构》出版一直到现在，软件行业对这种重构方法越来越接纳，请问背后的根本原因是什么？在这样的过程中，代码重构的实践方法有没有发生变化？
熊节：我不觉得行业对重构方法越来越接纳。整个行业而言，我们最常看到的还是“刀劈斧砍”，做出修改的时候过于乐观，没有测试、没有认真考虑行为保持的修改过程，出了问题就靠加班来解决。大家只是越来越接纳“重构”这个词，因为这个词听起来很好，有一种积极应对变化的感觉。但真正在做的，还是跟以前一样，毫无规矩的修改。
大家愿意接纳“重构”这个词，我想是和时代背景相关的。现在大家都在说VUCA、都在说拥抱变化，有这么一种能响应变化的方法当然好。但是这个方法，实际做起来又太费脑子，大多数人只是喜欢这个概念，并没有真的去学习和实践如何做测试、如何重构。
重构的实践方法其实一直就没有变化。我以前在ThoughtWorks的同事王健总结了一个口诀：“旧的不变，新的创建，一步切换，旧的再见”。如果我们去看具体的重构手法如何实现，很多时候都是这个套路。放在以前没经历过的变更场景（比如把系统架构由单体变成微服务），也是这个套路。
但这个套路有一个最大的难点，就是在“一步切换”之前，你会有“旧的”和“新的”两个东西存在，那么就会有一个或长或短的时间段，你需要同时维护这两个东西。这是有成本的。如果“一步切换”没有出错，这个成本就丢掉了。很多人非常乐观，会觉得我做这个修改一步就修改完了不会出错，所以他们就不愿意接受这个“旧的不变，新的创建”的过程。
盲目乐观和缺乏事后吸取经验教训的能力，这是我们这个行业普遍的现象。从改一个函数名，到改一个服务接口，到改一个架构，我们总会看到这种盲目乐观说“一下就改好了”的人，然后这次他出错了，下次他仍然会说“一下就改好了”。人们愿意盲目乐观相信这次不会出错，愿意出错之后通宵加班，也不愿意平时把测试做好、修改的时候选择一条行为保持的路径。在这一点上，我们这个行业相比十七年前，没有任何进步。
异步社区：最后，给刚入门的小白推荐3本专业书，您最想推荐哪一本？
熊节：一本的话，我觉得应该读《实现模式》。我经常看见号称七年八年经验的程序员，起个变量名都起不好。我觉得一个程序员至少应该先读《实现模式》，或者至少应该先读《实现模式》的第6章，否则应该禁止他编程。
三本的话，那就《实现模式》、《重构》、《测试驱动开发》吧。
从来不推荐什么“道”啦什么“禅”啦什么“思想”啦之类的。中国IT业的现实是能把代码写顺畅的人都太少。我们应该谦卑地直面这个现实，然后诚恳地做点实在的事情，不要成天就想着变成Linus。
作者：马丁·福勒（Martin Fowler）
本书是经典著作《重构》出版20年后的更新版。书中清晰揭示了重构的过程，解释了重构的原理和最佳实践方式，并给出了何时以及何地应该开始挖掘代码以求改善。书中给出了60多个可行的重构，每个重构都介绍了种经过验证的代码变换手法的动机和技术。本书提出的重构准则将帮助开发人员小步地修改代码，从而减少了开发过程中的风险。
- END -
