Re: real-world architectural refactoring in a dirty environment?

Starting with unit tests (tests which verify that individual
methods/object/components do a specific thing correctly) is nearly
impossible when you have a bowl of spaghetti instead of nicely layered
lasagna.

It probably makes sense to start with functional tests (test that verify
specific behaviors of the entire software).  Then, as you attempt to
refactor the software into decoupled components, you have a reasonable way
to verify that the software as a whole still does what it is supposed to do.

Once you have decomposed the software into decoupled components, then you
are in a position to work on each individual component (in priority order)
at a lower level of detail in order to drive down to the point where unit
testing becomes feasible.

This can take a long time, but usually less time than a total rewrite.  And
the components that prove to be stable can be left alone (possibly forever).

Even if you choose to rewrite, using functional tests to decompose into
components allows one to rewrite one component at a time and get value from
each rewrite by replacing the legacy version of the component with the
rewritten one (whereas a rewrite from scratch provides no value until
everything has been rewritten).

A hybrid approach is also feasible where the worst components are rewritten,
the mediocre ones are refactored, and the stable ones left alone.

My advice is to start with functional tests.  Doing so will probably
discover lots of previously unknown bugs.

SteveG

On Tue, Jun 21, 2011 at 6:56 AM, Donaldson, John (GEO) <
[email protected]> wrote:

> **
>
>
> Kristian,
>
> Did you read "Working Effectively with Legacy Code" by Michael Feathers? If
> not, it will be worth the investment.
>
> Apart from that, you can't really refactor much or well or confidently
> until you have some tests. So try to start by selecting a simple, small
> problem and put in place a couple of tests and then refactor. Then just keep
> taking small bites.
>
> Of course, you may need to refactor a little bit in the dark to begin with,
> just to get a testable piece of the application.
>
> John D.
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Kristian Rink
> Sent: 21 June 2011 13:23
> To: [email protected]
> Subject: [refactoring] real-world architectural refactoring in a dirty
> environment?
>
> Folks;
>
> hoping not to be all too off-topic with this here, I am looking for
> some fundamental insight in how others do architectural refactoring on
> a semi-large scale. Here's the situation:
>
> * Most of our business logic lives as customizing code inside a
> document management system. The amount of code in there has
> accumulated throughout the last 8 .. 10 years, most of the time being
> implemented in "quick hacks" to tickle a very specific customer need.
>
> * There is no substantial data model or architecture. Most of the
> customizing code is rather tightly coupled to / woven into the
> infrastructural aspects dictated by the document management system.
>
> * The system itself is built on top of a proprietary programming
> language which just exists inside this very system. There is no
> development, monitoring, testing, deployment, administration tooling
> support at hand.
>
> * The platform, as is, has no notion of an "external API" or support
> for _any_ kind of interface technology you might want to use. There
> is very crippled CORBA support (unusable to solve real-world
> problems), there is very crippled SOAP support, and there is next to
> no support for even things as fundamental as writing schema-validable
> XML. The only way of making this thing appear inside of a more
> "up-to-date" environment is a hand-crafted (and thoroughly buggy,
> thanks to the limitations of the language usable for that)
> HTTP-GET/POST structure transferring something akin to "JSON lite".
>
> At the moment, modifying, extending, maintaining the code base becomes
> more and more difficult, as complexity has by far reached a degree at
> which it has become next to unfeasible. We suffer from seemingly
> non-deterministic performance problems at times. We know that
> introducing new features takes ages simply due to struggling and
> fighting with the platform woes. We have quite to some extent dealt
> with refactoring and "brownfield" approaches, yet always and forever
> again ending up with the problem that, in this environment, we can't
> simply pull functionality out (or even refactor the thing as a whole
> initially) because we can't ensure that, after messing with the code,
> things still work, because we can't do reliable tests.
>
> So, this is the mess. We're on the edge between trying to pursue a
> slow, step-by-step migration away from this (to a more up-to-date
> environment to actually allow for meaningful work again) and throwing
> it all away and starting over anew from scratch, trying to make these
> things better by now. I am not really sure which of these options to
> choose, even technically. So, I'd kindly like to ask for any input,
> insights, ... into this. Does anyone around here have any experience of
> doing refactoring under conditions akin to these outlined above? What
> kind of lessons did you learn down that road? Any meaningful way of
> really handling with a situation like that?
>
> TIA and all the best,
> Kristian
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>  
>


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/