This week's book giveaway is in the Java 8 forum.
We're giving away four copies of Java 8 in Action and have Raoul-Gabriel Urma, Mario Fusco, and Alan Mycroft on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Organizing a long overdue refactoring Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Organizing a long overdue refactoring" Watch "Organizing a long overdue refactoring" New topic
Author

Organizing a long overdue refactoring

eric moon
Ranch Hand

Joined: Nov 26, 2000
Posts: 133
My company has scheduled a few weeks to refactor the Swing gui tool I'm involved with. It's been developed by an ex-vb programmer, and all the code is concentrated in a few classes. Its' working pretty well, but the code is a mess.
My question is this: does anybody have any experience working on a project like this as a team? My boss has asked how we plan to divide up the work between three of us. I'm not sure how much that is possible to do. Moving or renaming a class is going to change method calls in all of the major classes. Every class is going to have a ridiculous merge if we're working on them simultaneously. Nothing is currently encapulated much at all.
Here are some of the specific things we have targeted, if it helps:
1. The application inherits from JFrame. It's close to 5000 lines of code. We need to factor the non-gui elements into a new class. This class can then extend the company's generic application framework, eliminating a lot of code that was copied and pasted from there.
2. We need to implement the action model for menu items and toolbar items, and pull action handling out of anonymous inner classes (over 100 of them) in the main class.
3. The gui can contain multiple JInternalFrames in a desktop pane. The class that inherits from iFrame contains about 4000 lines of code. The table the iFrame is backed by data which can be in three distinc states, which affect the way it is manipulated, and I've thought it might be worthwhile to create several classes of this object, and use polymorphism to replace a bunch of the if/then statements. That might also better be done in the table, or the table model.
4. The table class is about 3000 lines of code. We want to factor out table oriented and application logic into a super and sub-class, so that we might one day be able to use the table in another situation.
5. And of course there's loads of feature envy to be corrected between the main classes.
Of course we may not get this far in two weeks.... But we at least need to get started. It's just hard to visualize doing this any other way than with two of us looking over the shoulder of the third. At least at the beginning.
Ideas?
Thanks in advance!

<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>"Those who cast the votes decide nothing. Those who count the<BR>votes decide<BR>everything." <BR> -Joseph Stalin<HR></BLOCKQUOTE>
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1441
Hi,
The first thing to do is have test(s) that verify the functionality of the GUI. If you don't have these your going to have to write them. Download JUnit if you haven't done so already.
As far as dividing the job up, just let people pick something they want to work on and do frequent integration builds. This sounds like XP would work very well for this and could be a good intro project.
John


The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
eric moon
Ranch Hand

Joined: Nov 26, 2000
Posts: 133
Well, I have heard it's difficult to create unit tests for gui work, and it seems that way to me. Can you recommend a source for info on this?
Thanks,
eric
eric moon
Ranch Hand

Joined: Nov 26, 2000
Posts: 133
Also, how would you recommend going about writing a test for a 5000 line class? This test alone is going to take our two weeks to write, and debugging the test itself is going to be a big issue isn't it?? Every article I've found on testing assumes you are writing a program from scratch, following good OOP principles, not starting with a huge wad of existing linear code.....
help??
John Wetherbie
Rancher

Joined: Apr 05, 2000
Posts: 1441
To be able to refactor you need to be able to test to see if your refactoring has broken anything. As far as the size of the class you are testing I don't think it really matters. ID the functions that provide the observable behavior of the class and write the tests to test these methods. This should be a subset of all the methods.
Since you are refactoring a Swing GUI, which is a bunch of Java classes, using JUnit to test the classes is pretty straightforward. Much easier than doing the same thing for an HTML interface.
Refer to Martin Fowler's book Refactoring. Its really great (possibly the most significant book since Design Patterns, in my opinion) and discusses a lot of this.
Good luck on the project!
John
[This message has been edited by John Wetherbie (edited March 28, 2001).]
[This message has been edited by John Wetherbie (edited March 28, 2001).]
Laojar Chuger
Ranch Hand

Joined: Dec 20, 2000
Posts: 111
Refactoring is always headche. Most of time it's a problem of how much time you want to put.
Here is my idea for your consideration:
1. Strictly separate view from the controller. That means the view should not have any action code except closing window and just like that.
2. Limit the use of inner class. There is a tendency to overuse of inner class which leads a huge GUI code.
3. Create interface for each type of action class. Each action listener should be a separate class.
4. Componentnize all the major part you intend to use as inside frame such as table, and put them in a separate class.
Laojar
Jim Baiter
Ranch Hand

Joined: Jan 05, 2001
Posts: 532
I think an interesting strategy is use short iterations and include a refactoring phase in each one. I believe XP advocates this.
eric moon
Ranch Hand

Joined: Nov 26, 2000
Posts: 133
The problem with small iterations is we didn't do one. We'll definitely have to do small steps in the refactoring, though! We will be creating separate classes for the actions. Problem is, nobody on our team has any experience testing, and I have only found one example of a GUI test, and that was where the tests were built simultaneously with the coding. It's also very basic.
Martin fowler's book is great, but so far, he doesn't ever talk about rewriting the tests after a refactoring. Doesn't this turn into extra overhead?
I will try getting JUnit, and trying it out with some small classes today, and try to get a feel for it. I guess we'll just do the best we can.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Refactoring without testing is like a high wire act without a net. It's fine as long as the high wire isn't more 6' off the ground, or as long as the code changes are only a handful of lines. Even then, how many times have you said,I'll just make these 3 small changes. Four hours later you can't figure out what went wrong until you eventually realize you made 2 mistakes in 3 changes, and those 2 mistakes interacted to make the problem much more complex. It's happened to me more oftne than I want to admit. Now imagine doing that to 5,000 lines of code.
JUnit isn't ideally suited for GUI, it's best for unit testing, not end user testing, but it's a start. The major QA Software comapnies have tools, such as Rational Robot, for automated GUI testing, but they are rather expensive (and may even be more web focused these days).
I agree that XP is best suited for this type of work.
Here's another question. How long would it take to rewrite from scrtach? I'm a big believer in "write once, throw it away, and write it again." I've often found that code which is seriously "misaligned" with it's purpose is easier to rewrite than to refactor. You're not doing it from scratch. You understand the major components. You've even got code for them. Everyone knows how it should look and how it should work. That's a pretty good start for any software project. The only question is can it be done in time. Whereas you can do some refactoring now, and some later, rewriting is an all-or-nothing deal.
We actually had a similar issue. A tool we had was written by a C programmer, so it was very monolithic; he even did some bizzar things, like passing values between modules by reading and writing them in files (he had far less Java knowledge than we originally thought). We ended up scrapping the tool, and rewriting.
Some of the modules we were able to port over. They each needed to be cleaned up. The easiest way to do this was first to design a new framework. Then we moved over one module at a time. As each module got moved, it was refactored to fit into the new framework. This would also allow people to work in parallel, since the old code base stays intact.

--Mark
hershey@vaultus.com
eric moon
Ranch Hand

Joined: Nov 26, 2000
Posts: 133
Wow, that is a very thought provoking approach. I will look at this with the team.....
Even then, how many times have you said,I'll just make these 3 small changes. Four hours later you can't figure out what went wrong until you eventually realize you made 2 mistakes in 3 changes, and those 2 mistakes interacted to make the problem much more complex

Where we're at, we're not having a great deal of trouble tracking down bugs--since one person did most of the code, and he's still with us, it's usually pretty easy to find the bug. However, there is very much the situation of bug propagation--we are very close to the 1.0 release, and it's unnerving to fix things, because they typically break something else, and even when that's easy to fix.....
We definitely need tests, and I think we have a guy developing automated user interface testing with JRobot or some such. But I gather it's going to be a while before that is available. I wish I could find more info on gui testing.
Thanks!
eric

[This message has been edited by eric moon (edited April 03, 2001).]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Organizing a long overdue refactoring
 
Similar Threads
Answers to IBM 486 sample test
Observable/Observer and MVC
Which framework to use in web layer?
GUI application design
Few Question For J2EE Developer