This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Large Scale Refactoring

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a rather large scale refactoring problem to solve, and I am looking for advice on where to start.

The J2EE applications that we support are about 10 years old now, and they have been sadly neglected. The original designers tried to build an enterprise framework to support 8 enterprise applications. The result is that all 8 applications are now tightly bound to the old technology. There's really old Log4J (with assert), very early Struts (with enum), and it all runs at Java 1.3 compliance levels. The problem is as soon as you try to upgrade one piece of the puzzle, you break all the other pieces.

The problem is compounded by the way the source code is managed. The shared libraries are included in each Java project, so we can't even update one application at a time. If we upgrade one, we are forced to upgrade them all. Finally, there are a bunch of cyclical dependencies in the projects that need to be untangled on top of all the rest, so it really is a big bad ball of string.

I thought of various approaches like just targeting the presentation layer and doing the Struts upgrade. Then I thought perhaps we could just start from the data layer and work our way up. Finally, I tried just breaking one little piece and trying to take the baby steps approach. However, I can't see any way to bring these apps up to current standards that won't require an army of developers working full time for a year.

Are there any approaches, tools, or experience reports out there that may help us get to where we need to be?
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What an interesting first post!

I thought of various approaches like just targeting the presentation layer and doing the Struts upgrade. Then I thought perhaps we could just start from the data layer and work our way up. Finally, I tried just breaking one little piece and trying to take the baby steps approach. However, I can't see any way to bring these apps up to current standards that won't require an army of developers working full time for a year.



From a birds-eye view, it seems like you have a few human capital issues. A suggestion would be to start thinking in terms of business services instead of "apps." In order to foster this direction, you need to have access to the right skill sets, and an "army" of developers will not help you, in my opinion. Building a service-oriented architecture is a long-term strategic mission that will take many years. There are many different aspects and benefits to consider, as well as organizational and technical challenges to deal with. Large technology organizations have architects and engineers that can help your organization. I suggest looking into hiring a few Business Service Engineers to help guide you.

Good luck!
[ May 06, 2008: Message edited by: James Clark ]
 
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
oh, yes that sounds like a real mess but i think this problem also very interesting (i am specializing in software architecture/quality and maintenance).

in my company we did a large scale refactoring some while ago. and the steps to restructure big areas of a system have to be planned carefully. many things have to be looked at (e.g. how is team working, what tools are used, what areas of the system needs to be touch, how strong are your regression-tests, what kind of and how many people are in the team, what version control system is used and how is source code layed out etc. pp). unfortunately there is no book out where the process itself of a large scale refactoring is discussed. some time ago i wrote 4 articles for german Java-Magazin about this topic. but is a german magazine and thus won't help you much.

my first thoughts regarding your special problem:
-change your dependency-management strategy. you mentioned, that dependencies/shared libs are put inside the project, so i guess that libraries are checked in version control system (which is very tricky to grasp overall dependencies and to upgrade)? to tangle out architecture/system smells, you need a proper dependency-management. look out for maven2 or ivy to introduce one. this can be done straight forward and you can accomplish this fluently (without affecting source code or alike).
-if version control is messed up, try to somehow tidy it up. version control system is one of your best friends, especially when refactoring. if you are lucky you are using subversion and moving folders is very simple and you don't lose your history (we migrated from CVS to subversion, just because of this advantage).
-the (only) good thing about cyclic dependencies is, that they can be removed, by introducing interfaces (one of robert c. martin papers explains how). on higher level if there are cyclic project dependencies, you need to find abstractions and move classes/interfaces to remove them (for instance by moving general stuff and introducing common-projects, or introduce an api project).
-you are lucky to use java. by removing a library from classpath you instantly see the red bubbles and know where the dependencies are (but watch out for dynamic things like reflection).
-use a whiteboard to discuss with the whole team (drawing pictures where you are and where you want to get).
-get the team into learning design principles/patterns. if known well know the target architecture and can plan your refactorings well, too. there are good books on refactorings (fowler, refactoring to patterns, large refactorings: performing complex restructurings successfully, working effectively with legacy code)

some more questions:
-you emphasized technical problems. is your main refactoring target to have the system upgraded to newer technology-versions (of struts, java, log4j etc.) only?
-what regression test suite have you got? how strong is it? one of the worst dangers of refactorings is to break existing behaviour.
-how big is the team?
-how much time have you got for the refactoring, how isolated can you do your refactoring (are bug-fixings and feature enhancements done in parallel)?

james clark is right. it is very difficult to help you, if one does not know and can see the system (just too many evil details to watch out for). you should really consist a consultant for that.
restructuring is bound to risk but if done well the whole team will be feeling good afterward and it really pays off business value too. but if it fails you can lose a lot of reputation inside your organization.

hope i could give you some ideas...
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pick an area -- a narrow vertical business service chunk if possible (rather than a whole app)

introduce an adapter layer between the external dependencies and the desired internal domain model. Now you have a clean "seed"

Find another two or three narrow vertical business service chunks -- ideally they should be slightly overlapping with the domain of the first. Grow the adapter layer and the domain model... you should be starting to be able to generalize/triangulate in on the better design.

Use tools to "find usages/dependencies" to find when the adapter layer is no longer needed within its vertical slice and you can implement the new correct/modern/cleaner access to new data/service providers,
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And get yourself a copy of "Working Effectively With Legacy Code" - and read it...
 
Water! People swim in water! Even tiny ads swim in water:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!