[
Lists Home |
Date Index |
Thread Index
]
At 08:42 +1100 2005-03-05, Rick Marshall wrote:
>Michael Kay wrote:
>
>>>My real "beef" is the 2666 line script. It has numerous
>>>redundancies (i.e. duplicate code) and looks like a nightmare to
>>>maintain.
>>>
>>
>>
>>It's a common problem. I once reduced a 2000-line stylesheet to 20 lines
>>plus some data tables. There are lots of people who learn how to write
>>concrete XSLT code without learning how to write it generically at a higher
>>level of abstraction. The same is probably true of most languages.
>>
>do you have an example? i'm working on a layout engine at the moment
>that's rapidly approaching that sort of complexity and i'd love to
>simplify it the way you described.
>
I don't have examples handy either, but I'll bet Michael's approach
will apply in your situation. The long form of learning to do this is
to study software engineering, of course. But a couple "25 words or
less" steps you can take might be:
1) Look for places where the program does the same conceptual thing,
in different ways (say, by iterating versus by recursion, or by
columns versus by rows, doing steps in different orders, etc). Pick
what seems the cleanest way, and change all the other places to use
it. Doing the same thing the same way several times, is clearer than
doing the same thing different ways multiple times.
2) Scan the entire stylesheet for repetitiveness -- places where
*almost* the same code appears multiple times. Figure out just what
the differences are ("these are just the same except for..."), and
then write a more general method that covers all the cases,
controlled by a switch, parameter, or other variables. It sounds like
you could get a lot of mileage here.
3) Look for a method that does the same thing as another, *except*
for not having to bother with one certain block of code. See if that
block does something coherent in itself, and try to factor it out to
make the larger method be like the smaller plus one extra method call
-- then you may be able to collapse them as in #2.
4) Go through and write a one-sentence (no more) description of what
each individual method does. Then read them all through in various
orders. This will likely stir ideas for further improvements. Also,
any methods where it's hard to write the sentence, probably need to
be re-thought and divided up more cleanly. Oh, you may want to insert
your sentences as comments over each method, to help the next person
(who may be you too, of course).
5) Draw out a diagram of what calls what. Switching from text to
visual modes may give you a whole new perspective on your code, and
simplifications may become easier to see. Use big paper, maybe with
post-its so you can re-arrange things several times.
There's my attempt at Software Re-engineering 101 in one page.... I
hope it's of some help; but this is a kind of situation where
training and experience can make a big difference. If these methods
or similar don't work for you, perhaps consider getting some highly
focused expert help.
Steve
--
Luthien Consulting: Real solutions to hard information management problems
Specializing in XML, schema design, XSLT, and project design/review/repair
Steven J. DeRose, Ph.D., sderose@acm.org
|
