他们总在说重构,不过是重写

发表于:2016-10-25来源:jianshu作者:溪石点击数: 标签:重构
大约是工作三年后,职业倦怠毫无征兆的袭击了我,我莫名的感到:这一辈子就这样了,每天的工作就是写相同的代码,要命的是,自己在一个领域越精通,别人就越希望自己写同样

  大约是工作三年后,职业倦怠毫无征兆的袭击了我,我莫名的感到:这一辈子就这样了,每天的工作就是写相同的代码,要命的是,自己在一个领域越精通,别人就越希望自己写同样的模块——再快一点。使我渡过这段时光的,是一些编程行业的老书,对于一个原本追求时髦技术的程序员来说,这样的反转令自己也很惊讶,其中就有这本《重构》,多年后,再次捧读,希望自己如《黑客帝国》里的neo,回到源码,去理解为何重构即不是传说中的银弹,却又如此重要。本篇为第一部分,先来说说看待重构的三心。

  回到源码

  抛掉对重构的敬畏之心

  1. 重构给出了具体的操作方法。

  重构不是建立在空中的构建思想,而是从实践中归纳出来的操作手册。比如书中提到的要点之一:

  事不过三,三要重构。

  这条规则给出了重构时机的具体判断方法:一个值,一段代码,相同的功能,如果重复出现了 两次以上,就要提取为宏,变量,方法,或模块,以方便重用。这不是建议,从代码质量来说,这是要求,也是开发者从小工到专家的必由之路,事实上,除此之外,我不知道还有别的编写代码的方法。

  2. 重构早已在开发者身边。

  几乎所有开发工具(Eclipse、Xcode...)都内置重构工具,他们的使用与代码编辑器一样简单。

  如果你是一名iOS开发者,请参阅Xcode8 五分钟重构起步

  要对重构有耐心

  由于重构不改变程序的外在表现,换而言之,即没有加入任何新功能,因此项目经理和老板不会主动要求开发者重构,甚至开发者提出时,会招来反对:这个项目还剩一个星期,还有N个需求未实现,现在你请求花费两天时间,什么都不做。开发者几乎都承担不了这样的压力,但是,比延误工期更严重的是,一个臃肿的,不易修改的项目,最终将面临添加需求困难,运行效率低下,以致达不到可用的性能,项目被砍掉,失败几乎不可避免。

  那么作为开发者,应该怎么处理这个矛盾呢?一个可行的方法是,把重构当做开发的一部分,一边开发一边重构,先快速的堆叠代码,实现功能,然后在功能不变的基础上(写好单元测试),逐步重构。

  庖丁解牛

  对于吹嘘重构有戒心

  不要对别人吹嘘重构

  重构是一系列技法,就如一个优秀木匠不会吹嘘自己的刀法一样,他表现自己的,永远是作品,开发者的作品就是程序,可扩展,少改动,高效,稳健的程序,如果团队里有人说:我现在不重构就没法写代码。大概他就真的只是不会写代码而已。

  本人面试过一些刚毕业的开发者,在最后的提问环节,他提出的问题是:你们用什么开发环境?接着他还进一步强调自己一定要使用Source Insight (一种Windows平台流行的开发集成环境,基于代码语义管理代码),否则就无法写代码。当时我有点错愕,面对了解公司环境的宝贵机会,不问福利待遇,不问升职通道,却纠结一个开发工具。后来我发现,很多初学者(也包括我自己)对工具有种痴迷,这当然也不是坏事,但对自己用的开发工具夸夸其谈,只能说明开发者的眼界不够开阔,水平有局限。

  木匠不会夸自己锤子好使

  当听到有人将重构奉为灵丹妙药,要格外小心,对此保持警惕。

  有的技术领导人,动不动就说“下面我们进入重构阶段了”,仔细观察发现:每每他提出的时机,都是项目无法按时完成,某些功能实现不了时,公司领导还无法反驳,懂点技术的都明白重构的重要性。

  忽悠

  那么,如何鉴别这种拿重构“忽悠”的行为呢?可以从以下几点:

原文转自:http://www.jianshu.com/p/bce0fe294655

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)