• 2013-03-06

    实践中的重构

    Tag:重构

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/229714206.html

    重构,早就不再是“奢侈品”,而是“日用品”。纵然如此,在自己的工作过程中,还是听到很多关于重构的误解。

    首先,重构是日常工作

    许多人问过我这样的问题,要不要拿出专门的时间做重构。作为一个程序员,重构就应该和写代码、写测试一样,是我们日常工作的一部分,只要你写代码,就应该重构。特别是当你在做TDD的时候,如果你只写测试,编代码通过,对不起,那根本不叫TDD,那叫测试先行。目前为止,我还没有见过一个程序员,包括我自己在内,写代码是一遍就写得非常整洁,无需重构的。通常都是第一遍写出的代码只能实现功能,然后,把它重构得符合整洁的要求。这里要说的重点是,别讨论专门拿时间做重构,那就是你日常工作的一部分。

    我知道为什么会有人问出这样的问题,这就是接下来要说的:重构不是重写

    对于很多人来说,他嘴上说的是重构,心里想的是重写,所以,这事很大,不是一蹴而就的,所以,要专门划拨时间来做。重写,事确实不小。但也是有技巧可言的。我们这里所说的重写,不是整个系统的重写,那专门立项就好了,这里所说的是要调整项目的某个模块,或是某个设计。

    一旦设计到调整,实际上是对整个项目组编码风格的一种影响,因为影响比较大,所以,可以考虑以技术债的形式在项目组内部提出来。如果项目组内达成共识,并且业务人员也同意给这件事留出时间,那就可以着手来做了。想要说服业务人员,最好是告诉他们,花多长时间做这件事,能给未来省下多少时间。即便所有人都同意这个调整的方案,真正在实施的时候,我们也需要按照重构的思路来做,这也是需要一些功夫的。

    没有测试的重构就是耍流氓

    对于ThoughtWorks内部的项目,测试多还是有保障的,但我周游天下时亲眼见过一些没有测试的巨大代码库,我能说的,赶紧花时间为你要写的代码补一些测试,然后再说重构的事。

    具体到动手重构了,标准只有一个:重构可以随时随地停下来,不破坏任何测试

    这话说得很容易,但真要做到可绝非轻而易举。我看到很多大动干戈的修改,中间无法停下,一旦发觉不对,只好推翻重来。我只能说,对于重构,这种做法只是理解了形,并不理解神。站着说话不要疼,事实上,我个人对重构的理解也是看到了有人用小步重构把一段代码逐步改好之后,震惊之余,才理解原来重构应该这样做。要知道,我也曾经是大刀阔斧之辈,那一刻,我皈依于小步重构。

    小步重构,是需要刻意练习的。我是花了不少时间去练习,才能做出一些当初见到的重构效果。时至今日,我依然不敢说自己有十足的把握能够小步重构每一段丑陋的代码,内心中总有一种躁动,想一路劈杀过去,只能不断与自己说,慢点,别急。

    对于ThoughtWorker而言,内部总是有这样机会见到小步重构,对于外部的人来说,经常参加ThoughtWorks的活动,应该也可以见到这种做法。

    重构易,程序员人人知重构,重构难,做好重构者寥寥无几。无它,刻意练习。

    分享到:

    历史上的今天:

    等在循环内 2007-03-06
    引用地址:

    评论

  • 重写和重构之间如何划分呢,假设,我以前写的代码比较的过程化,我现在把代码中的概念抽象出来,这样就对原来的代码改动很大。这算是重构还是重写?
    回复Benwei1988说:
    重构的概念在重构的书上,不改变外部行为。重写和重构不是最重要的,重要的是要有技巧安全地完成这一切。
    2013-03-28 17:48:36
  • 上交一位 thoughworks 的朋友分享了他们公司的敏捷经验,谈及页面上的测试也完全依赖于测试框架,自动测试,感觉好复杂的样子。
  • 以前写代码总是想一次性写的更好一些,现在慢慢的把心态转过来了,先把功能实现了,然后在提交代码之前再重构一次
  • 对于一些 ajax 交互比较复杂的页面,如何写测试用例呢?
    回复greatghoul说:
    首先,要搞清楚测试的层次。你说的是验收测试,可以采用webdrvier之类的框架来测试。如果再想加入单元测试,可以考虑用mock框架,模拟ajax的行为。
    2013-03-06 17:20:57