• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Organizing a long overdue refactoring

 
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Rancher
Posts: 1449
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
eric moon
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1449
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).]
 
Ranch Hand
Posts: 111
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 133
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic