This week's book giveaway is in the Android forum.
We're giving away four copies of Head First Android and have Dawn & David Griffiths on-line!
See this thread for details.
The moose likes Ruby and the fly likes Rails refactoring can become complex Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Head First Android this week in the Android forum!
JavaRanch » Java Forums » Languages » Ruby
Bookmark "Rails refactoring can become complex" Watch "Rails refactoring can become complex" New topic

Rails refactoring can become complex

Leandro Coutinho
Ranch Hand

Joined: Mar 04, 2009
Posts: 423
Hi. In this interview, the developer explains that he had difficulties performing larger refactorings.

How do you deal with this problem as your codebase growns?

Thank you!
Tammer Saleh

Joined: Mar 02, 2011
Posts: 11

Large refactorings are largely a mistake. The three important guidelines for dealing with any refactoring are:

  • Cover the existing behavior with integration tests. Simple smoke tests are a huge win for ensuring you're not breaking existing functionality.
  • Focus on a small part, one at a time. No matter how tempting it is to fix the whole application in one sweeping chunk, small iterations are always better.
  • Red, Green, Refactor. To avoid amassing a large chunk of technical debt, you should always be cleaning as you go.

  • Leandro Coutinho
    Ranch Hand

    Joined: Mar 04, 2009
    Posts: 423
    Yes, I agree. What IDE do you use? If you want to change the class' name. Is the IDE capable of change it everywhere?
    Katrina Owen

    Joined: Nov 03, 2006
    Posts: 1367
    In ruby there isn't a lot of (any?) tool support for automated refactorings, the reason being that the ruby language is extremely dynamic and objects can be defined at runtime. It's pretty hard to detect something that doesn't exist yet :)

    I believe RubyMine may have the closest thing to refactoring support, but I haven't ever used it so I wouldn't trust my judgement on that.
    Most people I know just use textmate or vim with various plugins, macros, and bundles.

    Thus, it is more important than ever to lock down existing behavior with characterization tests / integration tests.
    Tammer Saleh

    Joined: Mar 02, 2011
    Posts: 11

    Katrina is right in that a lot of the reason for the lack of IDEs with features comparable to those in the Java world is due to the dynamic nature of ruby. It's technically difficult to know what methods exist, for example, when methods are often created at runtime.

    On the other hand, this same dynamic nature makes a lot of the refactorings that IDEs traditionally offer less important. Ruby enables very DRY code, meaning there's very little boilerplate sitting around, and most refactorings are just as easy to accomplish with a good text editor.

    My personal "workbench" is simply:
  • VIM in one window with custom configurations, and Tim Pope's wonderful Rails Vim plugin. I've also blogged about using pathogen to manage your vim configs.
  • Autotest running in another terminal. Autotest (part of the ZenTest gem) simply watches for changed files and runs the appropriate tests. Makes for a very fast TDD workflow.

  • Sprinkle in a browser or two for click-testing and viewing docs, and that's about it.

    I agree. Here's the link:
    subject: Rails refactoring can become complex
    It's not a secret anymore!