aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes To the Author! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


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

To the Author!

Mcgill Smith
Ranch Hand

Joined: Nov 11, 2003
Posts: 178
Hi,

How is your book 'Working Effectively with Legacy Code' different to Martin Fowler's 'Refactoring' and Joshua Kerievsky's 'Refactoring to Patterns'?



Thanks.


Regards
Mcgill
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
According at least to the reviews on Amazon and especially the one of Jeanne I guess that the book is addressing complete another problems.

./pope


blog - InfoQ.com
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ali Pope:
According at least to the reviews on Amazon and especially the one of Jeanne I guess that the book is addressing complete another problems.

The focus is definitely different, but it seems like Michael's book is full of refactorings that'll make it easier to deal with legacy code. I'm sure Michael will clear many things for us once he comes through that saloon door


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
I have posted some long time ago a question about such a scenario: having a half working product without any documentation and/or real functional specs and facing a massive refactoring. (unfortunatelly I cannot find the real post... I just remember it was on the Testing forum).
I am looking forward to see author's opinion on this, but I will start a new thread for it.

./pope
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Both of the refactoring books, as far as I know/remember, only say "you should have tests to make your refactorings save".

The problem with "legacy code", though, is that it's *hard* to test. That is, you shouldn't refactor without having tests, but you also can't write a test without having the code refactored to be testable.

As far as I understand, this is the problem that is tackled by a big part of "Working Effectively with Legacy 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
Michael Feathers
author
Greenhorn

Joined: Aug 24, 2004
Posts: 24
Originally posted by Mcgill Smith:
Hi,

How is your book 'Working Effectively with Legacy Code' different to Martin Fowler's 'Refactoring' and Joshua Kerievsky's 'Refactoring to Patterns'?

Thanks.


Mcgill, I think Ilja hit the nail on the head below. I deal with the problem of how you get code under test to be able to use the sort of refactorings that Martin and Joshua describe. I think that is one difference. Another is that in many cases I'm talking about very sick code, so I have sections to deal with issues like understanding what is there and how to move to more appropriate design given the state that it is in.

In particular, you might notice that some of the end points I have in the examples aren't particularly pretty, but they are starting points. Once you have tests in place, you can make code arbitrarily better but you have to take that first step.


Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0131177052/ref=jranch-20" target="_blank" rel="nofollow">Working Effectively with Legacy Code</a>
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995

Another is that in many cases I'm talking about very sick code, so I have sections to deal with issues like understanding what is there and how to move to more appropriate design given the state that it is in.


Wow. Very interesting. I think also that the power of doing this comes from the length of experience.

./pope
Michael Feathers
author
Greenhorn

Joined: Aug 24, 2004
Posts: 24
Originally posted by Ali Pope:


Wow. Very interesting. I think also that the power of doing this comes from the length of experience.

./pope


Yes, I'd like to hear about your experiences too. You mentioned 'converting.' Were you talking about rewriting? Tying together legacy apps with message queues? Or, is it closer to what I've been talking about?

I got into this emphasis in an interesting way. I've helped a lot of teams transition to XP and Agile processes over the past five years. Those processes place a very strong emphasis on testing, and while it is relatively easy to show people how to do Test-Driven Development and move foward with that approach, it wasn't all that obvious how to move forward with existing code.. to refactor you need tests, but to test you need to refactor..

I started developing an arsenal of tricks with various teams to get past bad cases and decided to write them up when I discovered that practically every team I met had to confront this problem to some degree.
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
I am talking about all of them and maybe more. Let me give a little list of examples:
  • fully convert an application (this is a scenario very present in the last time)
  • refactor the core legacy application and present a new solution for user interaction. Legacy app prooved rock solid during the 2-3 decades already and the financial effort to migrate it is not worth it. The client needed a more uptodate client side.
  • refactor the core legacy application to use more uptodate technologies (for example removing from the legacy application the usage of not anymore supported databases)
  • last but not least, just taking a current (almost running ) solution and just makeing it maintainable (I think this is the point your book best applies, not because the other points are way to different, but because I believe the practices in so old app pieces are far way from our current solutions)


  • Having this large list of possibilities and working with highly heterogenous teams haven't allowed me to develop a team knowledge of this job. Rather I have learnt a set of good practices or as I call them my attack toolset.
    Jeanne Boyarsky
    author & internet detective
    Marshal

    Joined: May 26, 2003
    Posts: 30752
        
    156

    I think Ali hit all of the refactoring scenarios.

    "just taking a current (almost running ) solution"
    This one is interesting. Does it matter if it is almost running or completely running? Either way if it was written without tests, it needs refactoring to be testable. I was pleasantly surprised how useful the book is for code that was written less than a year ago and doesn't have tests for whatever reasons. I certainly don't consider that legacy code!

    Recently I was asked to compare rewriting at once vs rewriting by refactoring over time. After thinking about it for a while, I realized that both are ultimately refactoring. It's just a matter of when it occurs.


    [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
    Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
    Alexandru Popescu
    Ranch Hand

    Joined: Jul 12, 2004
    Posts: 995
    Jeanne I am using the sintagm "almost running" as I usually do not consider a bloated piece of code to be a running application. It just may run by hazard. Up until you have it clear and testing is just an almost running app.

    ./pope
    Jeanne Boyarsky
    author & internet detective
    Marshal

    Joined: May 26, 2003
    Posts: 30752
        
    156

    Ali,
    So "almost running" means something like it is working by coincidence? (just trying to check I understand right as it seems like an interesting way to describe things)
    Alexandru Popescu
    Ranch Hand

    Joined: Jul 12, 2004
    Posts: 995
    Yes, this is the meaning I wanted to express. Imagine you have a spaghetti code with no tests available, but the QA team (not using testing tools) reports it working. From my perspective (developer + maintainer) I cannot make any guarantee that that piece of code is not running by hazzard (coincidence). I would have to evaluate the QA test suite and start imagining any possible human scenarios. This will definitely take more time that a good refactoring session :-).

    ./pope
    Mcgill Smith
    Ranch Hand

    Joined: Nov 11, 2003
    Posts: 178
    Thanks Michael.
    Jeanne Boyarsky
    author & internet detective
    Marshal

    Joined: May 26, 2003
    Posts: 30752
        
    156

    Originally posted by Ali Pope:
    Yes, this is the meaning I wanted to express. Imagine you have a spaghetti code with no tests available, but the QA team (not using testing tools) reports it working. From my perspective (developer + maintainer) I cannot make any guarantee that that piece of code is not running by hazzard (coincidence). I would have to evaluate the QA test suite and start imagining any possible human scenarios. This will definitely take more time that a good refactoring session :-).

    ./pope

    Makes sense!
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: To the Author!