• 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

To the Author!

 
Ranch Hand
Posts: 178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

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



Thanks.
 
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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".
 
author
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
     
    author & internet detective
    Posts: 41860
    908
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.
     
    Alexandru Popescu
    Ranch Hand
    Posts: 995
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 41860
    908
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 995
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
    Posts: 178
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Michael.
     
    Jeanne Boyarsky
    author & internet detective
    Posts: 41860
    908
    Eclipse IDE VI Editor Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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!
     
    This looks like a job for .... legal tender! It says so right in this tiny ad:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic