This article follows on from A Spring Shortcoming that had a nice diagram:

The challenge

I now have a github codebase that is an very slim¹ example of that Spring app previously outlined. The code is 100% covered, though that is by accident as you will see on investigation. I have a challenge for folks.

Context: You are a developer who has just committed a change to this codebase. Before you tell your PM that you’ve finished it, you are going to embark on a refactor given you are acclimated to presently. We all love “Red, Green, Refactor” - right ?

1. You have seen that the controller you’ve been working on has two request-mapped methods ‘placeOrder’ and ‘seeSuggestedProducts’ should not be in that controller class. You want to fix both, by pushing them to new controllers You also suspect that UpSell should be a collaborator (but still request scoped).
2. Using Intellij or Eclipse Refactoring operations, attack one of the two misplaced request-mapped methods first, try to move it to a new class. v Work out part way through that you should have started in the wrong place² and instead should use the same techniques for ‘findUpsell’ first, and made a collaborator class of that.
3. Flushed from that success, you should be able to go back to both of the other misplaced methods and pushed them using refactoring operations to new classes.

You are not going to be able to do it all with refactoring operations. Ctrl-Z or abandoning changes in Git will be part of the workflow for the above when you confirm you have taken the wrong direction. Cut/Paste is going to have to happen too sadly in a couple of places, as Intellij can’t do all your intended moves for you.

If you are willing to record and publish a video of the series of refactorings, I will link to it from this posting or a follow up.

The take away?

.. should have been do “least depending and most depended on” components first². Jeez, there’s only one hit for that in Google. Was it mentioned in the Michael Feather’s book?

Responses

Dec 10, 2011: Danilo Sato has has a blog entry in his series on the differences between Mechanical and Strategic refactorings, and their benefits. He’s got a 14 minute video walkthrough of the refactorings needed as you push towards “most stable” code.