• 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
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Mikado: breaking out of Catch 22

 
Marshal
Posts: 14494
240
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ola and Daniel,

First of all, thank you in advance for spending time with us this week to explain the subject of your upcoming book.

I got the MEAP notice about your book last week and the title piqued my interest enough to actually take a look at its MEAP page. It sounded very promising and I actually went ahead and took advantage of the discounted MEAP and ebook deal. I was hoping to start reading the available chapters soon and start sending in feedback but since you're here this week, that's even better!

Brownfield development is my bread and butter. It's also one of my greatest sources of stress and frustration. The most difficult and challenging brownfield development is when you have legacy code (in the Michael Feathers sense: no unit tests) that is not only convoluted and incoherent but highly coupled as well. This makes it difficult to nearly impossible to write unit tests that make it safe to refactor. Michael Feathers' book "Working Effectively with Legacy Code" has been a great help to me over the years in creating enough wriggle room to start the long and arduous task of refactoring really bad legacy code.

I actually have two questions for you:
  • Does Mikado have specific recommendations for breaking out of the "between a rock and a hard place" situation you often find yourself in with legacy code?
  • What does Mikado add to Michael's strategies, if anything, and how is Mikado different, if at all?


  • Thanks!
     
    Author
    Posts: 10
    5
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Junilu,

    a) The method itself /only/ suggests that you don't do any additional changes if the code is broken, i.e doesn't compile, breaks tests or just isn't functioning the way it should. And I guess this is where 'the rock and a hard place' comes in. It's the "I can't add a test safely, and I can't change code unless I have a way to test things". The crux of the questions is really how to balance safe changes and fast enough progress. First, we need to balance between the need for a change to be absolutely safe and secondly. Secondly how long can we wait before we know the effect of our change.

    So, if it dictates anything I would say the extensive use of _reverting to a know state_ and _trying to do the smallest change you can get away with_.

    b) What I believe is the biggest 'add-on' to Michael's work is the systematized use of what he calls 'scratch refactorings'. Where a 'scratch refactoring' is a change you do, then restore the code, only to learn about the system.

    The Mikado Method makes extensive use of this and encourages you to:
    - Try a change
    - See what happens
    - Make a not of one possible solution to that on a piece of paper
    - ... and then revert the code to it's initial state

    Then you repeat the process until you can actually achieve something.

    It adds to Michael's work and if you have read WELC (which I encourage all to do), you will see that the Mikado Method is a natural extension to his great book.

    //Ola

     
    My pie came with a little toothpic holding up this tiny ad:
    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!