Re: Refactoring wishlist

I have never needed more than rename, move, and a few extract/inline
heuristics for appropriate abstractions (e.g. in java extract/inline
method/class/abstract parent/interface, in ruby extract/inline
method/block/module/class, etc.) I basically ignore all the rest of the
stuff in the menu.

Everything else I can compose from these, and if it is really something that
is "very tricky to get right" I want to do it in baby steps guided by
tests.

The problem with advanced tool support for refactoring is it is a lot like
working with other tools/frameworks. As long as you are working exactly the
way that the tool/framework creator intended it can save you some time, but
the minute you go against the grain it can cause you more pain than just
changing the code by hand (Ask anyone whose done a non-trivial Rails
project.)

Also, if you understand how to perform complex refactorings as a series of
atomic steps (Which is how Fowler et al describe it in the book) then you
not only grok them but you can even start to innovate your own complex
refactorings when the domain/language is different.

< / two-cents >

On Mon, Sep 19, 2011 at 7:03 PM, Danny Dig <[email protected]> wrote:

> **
>
>
> Refactoring tools have made a big splash. They are now in the
> top-level menu (along File, Edit) in most respectable IDEs. On one
> hand, this is good news. On the other, we could have done more.
>
> At every single refactoring workshop that I held in the past, somebody
> inevitably asks the question: "Martin Fowler's catalog lists 90+
> refactorings. More than 10 years after its publication, major IDEs
> like Eclipse only automate about two dozen of those refactorings. When
> are we going to automate the remaining refactorings?".
>
> I would like to automate many more refactorings. This semester I have
> the man-power to do this. I am teaching the Software Engineering
> course at UIUC with 160 students. For the class project, each group of
> 4 students will implement a new refactoring in the Eclipse IDE.
>
> Two kinds of refactorings are worth automating. First, refactorings
> that you perform very infrequently, but are very tricky to get right.
> Second, refactorings that you perform very frequently; you are not
> frustrated because they are complicated, but because you have to do
> them so often by hand.
>
> For the class project we would target refactorings from the latter
> category (simple, but frequent). What are some refactorings that you
> wish we would automate?
>
> best,
> Danny
>
> --
> Danny Dig's homepage: http://netfiles.uiuc.edu/dig/www
>
> Motto: "Success is not for the chosen few but for the few who choose"
>  
>


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/