This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes New to Refactoring Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "New to Refactoring" Watch "New to Refactoring" New topic
Author

New to Refactoring

C Kutler
Ranch Hand

Joined: Apr 15, 2004
Posts: 62
When evaluating IDEs what type of refactoring features should I look for?

What are the types of refactoring that you do mostly (such as several times a day)?

Where does refactoring save you the most time?


We learn by doing, there is no other way.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
C Kutler:

When evaluating IDEs what type of refactoring features should I look for?

"Copy" and "paste" features, so you don't have to retype the refactored code by hand.

What are the types of refactoring that you do mostly (such as several times a day)?

Probably the only type of refactoring that I do more than daily is functional decomposition, specifically, separating out any code that is used in more than one place into its own function. Sometimes this involves moving the function to a different class, but I'm not sure that's more often than daily. I'm pretty sure new classes get created due to refactoring less than daily for me.

Where does refactoring save you the most time?

Debugging. By separating tested code into a reusable function, I avoid reintroducing bugs each time I have to do the same task in another place.
[ May 21, 2004: Message edited by: Warren Dew ]
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
When evaluating IDEs what type of refactoring features should I look for?

As many as possible, especially the ones that are tough (or tedious) to get right "by hand"

What are the types of refactoring that you do mostly (such as several times a day)?

Without a doubt the refactoring I use most often is "rename". I use it for classes, methods, and values as soon as I find that what something is used for does not match it's name. If you've not used a refactoring tool for this, you probably haven't even realised that this is powerful, or useful.

Where does refactoring save you the most time?

I save time by not having to step through tens (or hundreds) of files fixing trivial syntax errors after a sweeping find/replace operation. I save time by having code that's free to be as readable and understandable as I can make it, without worrying about the effort needed to change something.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
Originally posted by Warren Dew:
C Kutler:

What are the types of refactoring that you do mostly (such as several times a day)?

Probably the only type of refactoring that I do more than daily is functional decomposition, specifically, separating out any code that is used in more than one place into its own function. Sometimes this involves moving the function to a different class, but I'm not sure that's more often than daily. I'm pretty sure new classes get created due to refactoring less than daily for me.



I'll agree with Warren that (besides Frank's obvious catch of "rename") the most common refactoring I do every day is also functional decomposition. I'd also like to point out that Eclipse (and thus WSAD) includes a handy menu option for this called "extract method" that does this with one mouse click.

Kyle


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Kyle Brown:

I'll agree with Warren that (besides Frank's obvious catch of "rename") the most common refactoring I do every day is also functional decomposition. I'd also like to point out that Eclipse (and thus WSAD) includes a handy menu option for this called "extract method" that does this with one mouse click.

I'm holding out for an IDE that automatically does the most time consuming part for me - writing a good header comment for the function (or writing the test for Ilya).
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112

What are the types of refactoring that you do mostly (such as several times a day)?


The following are the ones which instantly come to mind and are all fully automated in Eclipse (certainly also IDEA)

Rename class/method/variable
extract method/local variable/static final field
inline method/local variable
anonymous to nested class
nested to toplevel class
change method signature (add/remove parameter)

There are certainly more I forgot to mention, let alone all the quick fixes and quick assists.


Where does refactoring save you the most time?


That's like asking a cook "where does keeping the kitchen clean save you the most time?"

Keeping the code clean just ensures that I can develop at top performance, without being distracted by hard to read, duplicated and misleading code.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
C Kutler
Ranch Hand

Joined: Apr 15, 2004
Posts: 62
Thanks for all the input. I think this will be interesting to explore. I especially get the point about keeping the code clean. I certainly find myself wanting to go back and clean up code, but that usually happens when there is time (which is almost never) and when modifying/expanding existing code.

Questions:

Frank wrote
[the refactoring features] that are tough (or tedious) to get right "by hand."
Can you expand further?

Ilja wrote
quick fixes and quick assists.
Can you expand further?

Waren wrote
(or writing the test for Ilya)

What is Ilya?


So far, I think that when evaluating an IDE, I would want to make sure it had at least the following, as they work on the current source and all other "users" of the thing being refactored, and can save time and keep code more readable:



Renaming classes, methods, and variables and having all uses of that object renamed as well.

Change Method Signature

Quick fixes ???


Of slightly lower priority:

Extract Method (aka Functional Decomponsition). Ability to select code and turn it into its own function.

Extract local variable/static final field


And nice to haves

[LIST]
inline method/local variable
anonymous to nested class
nested to toplevel class
</LIST]>

Is this about right? Any more things to look for?
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
C Kutler:

What is Ilya?

Oops, I meant Ilja (who posted right after me) - sorry Ilja!

There was a thread a couple weeks ago where I came down in favor of writing header comments for public functions, and Ilja felt that the automated unit tests were generally a good substitute. I don't think I'd trust the IDE to write either without the programmer's help.

I have to say I'm unconvinced of the benefits of automating a lot of the tasks mentioned, as only the easy parts can actually be automated. Renaming, in particular, I'd be leery of: while the IDE can rename all references in the code, it can't automatically update the references in the memory of the other people working on the project, so large amounts of renaming is going to result in at least some time lost due to confusion.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
Renaming, in particular, I'd be leery of: while the IDE can rename all references in the code, it can't automatically update the references in the memory of the other people working on the project, so large amounts of renaming is going to result in at least some time lost due to confusion.

This is actually one of my biggest worries about the future of software development. I'll be (relatively) brief here, but I've got an article in the works about this.

Software (especially when you include the broader surrounding context such as deployment and configuration options) is incredibly malleable. Anyone can change any apsect of it at any time. Ultimately, this flexibility and adaptability has always been the key to the power and success of software-based projects. As the pace of life and development continues to increase, the only way to cope with changing requirements and needs is to make software even more fluid, so it can fill each tiny niche as soon as it opens.

And yet, the people and organizations producing software have, on the whole, embraced an obsolete model of learning and skills. You can observe it everywhere, from job ads to college prospectuses, from design documents to instruction manuals. The dangerous assumption that something, once learned, is learned (and useful) forever.

Just about every software-related job I've had, I have seen the expressive and flexible power of software walled in and pinned down by arbitrary processes and rules designed to pretend that what someone thinks they know, or have on a piece of paper, is still valid.

The following quote (from Spike Milligan in the "Goon Show") seems absurd:


What time is it, Eccles?
Erm, just a minute I got it written down on a piece of paper. A nice man wrote it down for me this morning.
It's writted 8 o'clock. But wait a minute. What if someone asks you the time, and it's not 8 o'clock?
Well, then, I won't show it to them.
Well, how will you know when it's 8 o'clock?
I got it written down on a piece of paper.


But why should remembering (or documenting) the transient state of software be any more sensible? Do you keep your own private list of web bookmarks any more, or (like the rest of us) have you been burned too many times by vanishing sites and changing URLs, and now rely on a search engine? Free the code from the shackles of memory! Don't remember, ask!

Sorry if that came out as a rant!
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Frank Carver:
Do you keep your own private list of web bookmarks any more, or (like the rest of us) have you been burned too many times by vanishing sites and changing URLs, and now rely on a search engine?

Yes and yes. I keep bookmarks, but mostly use a search engine...


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Frank Carver:

But why should remembering (or documenting) the transient state of software be any more sensible? Do you keep your own private list of web bookmarks any more, or (like the rest of us) have you been burned too many times by vanishing sites and changing URLs, and now rely on a search engine? Free the code from the shackles of memory! Don't remember, ask!

I keep hundreds of bookmarks in a dozen or two categories. Very few of them have ever vanished - frankly, I'm more often burned by vanishing storefronts and such in the brick and mortar world. And even when a bookmark does, after years, change so it's no longer useful, I've gotten years of convenience out of it where I didn't have to waste time on a search engine.

Software is written for the benefit of human beings, not vice versa.

But that does bring up an idea. Perhaps an IDE should be able to let you change your own personal alias for each variable or other symbol, without disturbing everyone else's.
C Kutler
Ranch Hand

Joined: Apr 15, 2004
Posts: 62
First the easy and quick question:

Ilja wrote "extract method/local variable/static final field"

As I understand it, "extract method" is what others call functional decomposition and I assume this to mean that I select some code and the refactoring tool moves it into its own function (and figures out the signature and return value, if any).

For "extract local variable/static final field," does this mean "encapsulate variable" as in make private with getter method and with setter method if appropriate (e.g., not final)?

Now for the long question:

Frank makes some good points and provides me a segueway to a question I asked earlier in this same Forum about when to bring out the UML tools.

I have to admit that I did not fully understand why this forum covered UML and refactoring (I vaguely thought it had to do with taking legacy code and refactoring into patterns). However, this thread has provided another link.

Is it possible that a good round-trip-engineering UML tool (class diagrams to code and vice versa, for example) would produce the kind of API information that would obviate the need to keep method names in memory?

If I knew that I could easily get API docs and diagrams that always reflected the current state of the software, then could I offload some of the info I have stuffed into my gray matter?

Nice in theory, but what about practice? Does anyone reading this actually use reverse-engineered UML diagrams as a way to keep up with refactoring changes made by others?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Warren Dew:
I have to say I'm unconvinced of the benefits of automating a lot of the tasks mentioned, as only the easy parts can actually be automated. Renaming, in particular, I'd be leery of: while the IDE can rename all references in the code, it can't automatically update the references in the memory of the other people working on the project, so large amounts of renaming is going to result in at least some time lost due to confusion.


This doesn't happen to be a big problem in the presence of

- a good configuration management system and
- the practice of Continous Integration

With other words, it basically just requires you to check in and update changes frequently, to have a CMS with good conflict resolution strategies and good team communication.

In my experience, the expressiveness of good names is well worth the overhead of organizing the appropriate refactoring.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by C Kutler:
As I understand it, "extract method" is what others call functional decomposition and I assume this to mean that I select some code and the refactoring tool moves it into its own function (and figures out the signature and return value, if any).


Basically, yes.

Eclipse is also able to find similar blocks of code in the same compilation unit (.java file) and replace them with the method call.


For "extract local variable/static final field," does this mean "encapsulate variable" as in make private with getter method and with setter method if appropriate (e.g., not final)?


No, it does mean to select an expression and replace it with a local variable (constant), which gets initialized with the expression.


Does anyone reading this actually use reverse-engineered UML diagrams as a way to keep up with refactoring changes made by others?


No, not at all. Instead, I use the browsing facilities of the IDE.

For example, If I want to know which classes in the hierarchy implement a specific method, I just select the method and press ctrl-t. The same shortcut on the class name gives me the whole hierarchy, including all inherited methods.

And if I don't easily find something, I just ask into the room. Quite effective!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by C Kutler:
Ilja wrote

quote:
--------------------------------------------------------------------------------
quick fixes and quick assists.
--------------------------------------------------------------------------------

Can you expand further?


Quick Fixes: When you press ctrl-1 on a compile time error or warning, Eclipse will give you a list of possible fixes (introducing a cast, changing the return type of a method, removing an unused private method or local variable, adding throws clauses etc.). You can choose from this list and Eclipse will apply it automatically.

Quick Assist: The same hot key pressed when you are not on an error or warning will give you context sensitive assistance: Used on a method argument, you can assign its value to a newly introduced field; you can surround selected code with an if/while/synchronized/...-block and dozens, if not hundreds of other things.


Of slightly lower priority:

Extract Method (aka Functional Decomponsition). Ability to select code and turn it into its own function.

Extract local variable/static final field

And nice to haves

inline method/local variable
anonymous to nested class
nested to toplevel class


Is this about right? Any more things to look for?


To me, those are not low priority or nice to haves, but essential - I wouldn't want to work without them any longer. And there are literally a hundred of other Eclipse features I use intuitively today without even noticing.

We are now using Eclipse for more than two years at work, and for someone who isn't used to it, it looks like magic - the code really gets *soft*, like a fluid. And even for us, when we pair with a new partner time and again you hear "Wow - how did you do *that*?" - "Uh, don't know, my hands are doing it automatically. Let's see..."

And people tell me that IntelliJ IDEA is even better...
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
BTW, to get a feel for how far refactorings and quick fixes can go, take a look at the new features in the new M9: http://download2.eclipse.org/downloads/drops/S-3.0M9-200405211200/eclipse-news-part2-M9.html

And there are three important refactorings I forgot:

Move Method, Pull Up Method/Field and Extract Interface.
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Ilja Preuss responding to me about renaming:

This doesn't happen to be a big problem in the presence of

- a good configuration management system and
- the practice of Continous Integration

With other words, it basically just requires you to check in and update changes frequently, to have a CMS with good conflict resolution strategies and good team communication.


It doesn't have to be a big problem to bother me. Even small amounts of unnecessary overhead can cut into my productivity. A good merge tool makes things easier, yes, but better yet is not having to do the merge in the first place.

In my experience, the expressiveness of good names is well worth the overhead of organizing the appropriate refactoring.

I agree with that - if the previous name was misleading or inadequately descriptive, or if previous refactoring has made the name obsolete, a good descriptive name is worth a renaming.

In my experience, though, the best way to get good names is to start with them. In my experience, the average name change is not actually an improvement - it's just a change. I've seen nearly as many name changes that are demonstrably changes for the worse as changes that are for the better.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Warren Dew:
In my experience, though, the best way to get good names is to start with them.


Yes. Perhaps it's just me, but often by using a thing my understanding of it, and therefore my ability to name it, increases. So it happens quite often to me that I find better names for something after I have used it for a while...

In my experience, the average name change is not actually an improvement - it's just a change. I've seen nearly as many name changes that are demonstrably changes for the worse as changes that are for the better.


That sounds bad, yes. Doesn't match my experience at all, though. Wonder where this is coming from - how well is team communication working for you? Do you discuss naming matters in the team when they arise?
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Ilja Preuss regarding bad name changes:

That sounds bad, yes. Doesn't match my experience at all, though. Wonder where this is coming from - how well is team communication working for you? Do you discuss naming matters in the team when they arise?

I've worked on two projects where there were a lot of name changes, most of which were bad in both cases.

In the first one, the team communicated well. However, our task was to upgrade a system that we didn't, at first, understand - it included a lot of specialized and complex algorithms that had been developed specifically for the task in question (long term prediction of polyethylene production capacity, which the system did pretty well). In retrospect, the original names were actually fine, albeit sometimes quite ambiguous due to abbreviation (the language had a 31 character name length limit - this was more than a decade ago). We didn't understand the names at first, though, so we figured we would "improve" the name whenever we thought we knew what it meant. This process actually resulted in the names getting worse rather than better, and also impeded our progress in learning enough about the system to actually work on it productively. Eventually we had to start over from scratch. In more recent projects when I've been on teams in similar situations, we've had much better luck putting our guesses in comments - with initials and dates, so we'd have some hint about how good our understanding was when the comment was made - and leaving the names alone until there was some other reason for changing the code.

The other case probably was in fact a communications problem. This team believed in "no code ownership", and one person, in particular, took that as license to change all names to his taste, without regard for whether the changes made the names more or less clear to other people on the team. In general, they made them less clear to everyone except possibly himself. Then again, this was the same person who would, when his changes broke the build, just remove the algorithmic tests from the test cases that got broken and replaced them with simplistic tests that just checked return types and such, so I'd definitely say there was a lack of teamwork there.

The vast majority of the teams I've worked on have not had such problems - but they also haven't ended up making name changes unless the code was also changing enough to justify new names.
 
 
subject: New to Refactoring
 
Similar Threads
Refactoring
Open Source Tool for Code Refactoring
Program Structure
book: reflection in action
Reasons for refactoring ?