A more agressive suggestion
Steve Eckhardt
OK, now you've done it. You've been so gracious and receptive that
I woke up this morning thinking about how I'd start your book.
Pedagogically, one should always start with the known and move to the
related unknown, so here's a stab at an outline:
I. The Problem
A. The product of a failure (from Ch. 3)
II. Solutions for Application-Level Refactoring
A. Rewrite from scratch
1. Description
2. Pros
a. No code deciphering
b. Architecture is right from the start
3. Cons
a. See Spolsky,
http://www.joelonsoftware.com/articles/fog0000000069.html
b. Doesn't fit into one release cycle unless
the program is small; see Rule of Thumb
Rule of Thumb: Programmers and customers should both see improvements at
the end of each release cycle.
B. Big Bang
1. Description: Create a new architecture and move
existing code into it
2. Pros
a. Code reuse
b. Test reuse
c. New architecture
3. Cons
a. Does it obey the Rule of Thumb?
b. No fully functional app until done
C. Divide and Conquer
1. Description
a. Recursive subdivision, starting at the
program level
b. Can use Feathers' Seam Method (Legacy Code)
2. Pros
a. Code & Test reuse
b. App always works
3. Cons
a. Does it address getting to a new
architecture?
b. Does it obey the Rule of Thumb?
c. Can it be done by a team?
D. Strangler Method (Fowler)
1. Description (see web)
2. Pros
a. Incremental; meets Rule of Thumb
b. Provides overarching objective
3. Cons
a. Provides no guidance on implementation
E. Refactoring (Fowler)
1. Description (see book)
2. Pros
a. Provides specific tactics
b. Incremental; meets Rule of Thumb
c. Lots of available tools
3. Cons
a. Function-level only
b. Doesn't provide guidance at app level
F. Seam Method (Feathers)
1. Description (see "Working Effectively with Legacy
Code")
2. Pros
a. Provides enabling tactics
b. Works at app level
c. Incremental
3. Cons
a. Doesn't address goal or architectural
considerations
b. Just a tool; needs a framework
G. Uncle Bob's Advice
1. Description
a. Agile Software Development book
b. Clean Code book
2. Pros
a. Provides specific tactics and metrics
b. Helps establish architecture
c. Can be applied incrementally
3. Cons
a. Doesn't tell how to do app-level refactoring
b. Just tools; need a framework
H. Ideal Method
1. Incremental
a. Meets Rule of Thumb
b. Reuses existing code and tests
2. Prescriptive
a. Specific guidance for app-level refactoring
b. Describes goal and process for getting there
c. Builds on existing incremental tools
3. Visual
a. Encodes intention and progress
b. Communicates goal and process to others
c. Provides status reminder to self
4. Mechanical
a. Steps can be done and undone
b. Entire process can be automated
c. Diagram can be linked to automation, like
UML to code generators
III. The Mikado Method
A. The Game
B. The Diagram (of the game)
IV. An example in code
A. (Existing Ch. 2)
You are, of course, free to accept or ignore this suggestion. For me, it
was a great exercise in assembling what I know into a framework and
evaluating each of the techniques I've heard about. Listing their pros and
cons and where they fit into the grand scheme was really helpful. And then
dreaming about the ideal method was fun. The outline shows how close the
Mikado Method comes to my ideal and why.
Wouldn't it be great to open a window in VS or Eclipse, draw a goal, and
then start drawing steps? After that you could right-click the step icon
and select "record script", make changes to the code, and save the script.
Undo, test, redo, test, modify, test... Anyone want to turn a dream into a
reality? I'd even settle for the text version in the short term.
Best regards,
Steve Eckhardt
-----Original Message-----
From: mikado...@googlegroups.com [mailto:mikado...@googlegroups.com]
On Behalf Of Daniel Brolund
Sent: Wednesday, October 06, 2010 1:04 AM
To: mikado...@googlegroups.com
Subject: Re: New version of the book
Hi Steve,
Thanks, we appreciate your very constructive feedback! :-)
Daniel Brolund
Thank you for your suggestion. We suddenly got a bit quiet... ;-)
Seriously, we had to discuss your idea a bit, since it has its merits.
Our conclusion is that we want the book to be about the Mikado Method
first and foremost, and we want to get to that as quickly as possible.
However, your suggestions on how to explain the shortcomings of
current strategies, and how the Mikado Method fits in, is appealing.
We want to add a section where we detail the current state a bit more,
and your structure will probably be a good starting point.
And about the automated tool, we've been thinking about that too, but
haven't gotten around to implement anything. :-) What I did in one
project was to make almost every node automated with either regexps,
scripts or automated refactorings. Then it was a breeze to repeat the
process. Adding a Mikado layer on top of that would probably add a lot
of value with a small effort.
Cheers
Daniel
> --
> You received this message because you are subscribed to the Google Groups "Mikado Method" group.
> To post to this group, send email to mikado...@googlegroups.com.
> To unsubscribe from this group, send email to mikado-metho...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mikado-method?hl=en.
>
>
--
---------------------------------------------------------
Daniel Brolund
Agical AB - www.agical.com
work: daniel....@agical.com
phone: +46708754002
blog:http://danielbrolund.wordpress.com
twitter: @danielbrolund
private: daniel....@gmail.com
Steve Eckhardt
Thanks for considering my suggestion. As I hinted, the outline was
mostly for my own benefit. I have now taken the time to ponder each of the
alternatives for application level refactoring at a deeper level, which has
been very helpful. If you have also benefitted, so much the better. And if
your book has a section on current strategies, that is better yet.
The automated tool was, of course, a dream. If you want to add a
section in your book with suggestions for how to automate the process, that
would be great.
Best regards,
Steve
Alan Baljeu
Honestly, I think it might serve quite well as a chapter comparing
other methods directly to Mikado. Explain Mikado, give an example or
two, give the philosophy, and then bang out this chapter. Sections A
and B can be shown as bad approaches. Sections like Refactoring,
instead of giving pro and con, can be presented as
a) Here's Fowler's idea.
b) Delve into some details
c) How Mikado can can take advantage of the techniques, and maybe
extend, improve or manage them.