任何一个傻瓜都可以写出计算机可以理解的代码,唯有写出人类容易理解的代码,才是优秀的程序员。
——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版)》
作者:[美]马丁·福勒(Martin Fowler)
**译者:**熊节 林从羽
编辑推荐:
世界软件开发大师MartinFowler的不朽经典
普通程序员进阶到编程高手的修炼秘笈
它在世界范围内畅销不衰,被翻译为中、德、日、俄等众多语言。
这本经典书20年后重磅升级,更新内容超30%,更新了众多项目案例。
本书是经典著作《重构》出版20年后的更新版。书中清晰揭示了重构的过程,解释了重构的原理和最佳实践方式,并给出了何时以及何地应该开始挖掘代码以求改善。书中给出了60多个可行的重构,每个重构都介绍了种经过验证的代码变换手法的动机和技术。本书提出的重构准则将帮助开发人员小步地修改代码,从而减少了开发过程中的风险。
-END-