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

Folks;

first off, thanks very much for your interesting insights and thoughts
on that. To add a few comments:

> That should be http://martinfowler.com/bliki/StranglerApplication.html

Yes, I already stumbled across this a while ago, and I also dealt with
the WELC book for quite a while, all along with Fowlers Refactoring
book, the Clean Code Handbook and the Elephant / brownfield book. All
these, though particularly useful and rather interesting in terms of
learning and improving, so far left me with a couple of questions I
eventually lack experience to really deal with (the difference between
"knowing from books" and "knowing from having done a dozen times
before"):

- Starting with WELC, most of the approaches are obviously built around
  the idea of building a skeleton of reliable (functional, unit, ...)
  tests to refactor without putting the whole mess at risk.
  Unfortunately, in our environment, most of the core logic is
  implemented in a technology / language which, apart for a half-baked
  unit test framework that doesn't work right, doesn't have useful
  support for any kind of testing. So, doing functional testing almost
  immediately will end up building some sort of external logic and
  somehow attach this to the backend system, which is difficult because
  there is no real interface technology to do so. So, in order to do
  meaningful functional tests in any way will require a drastic amount
  of work and a bunch of fragile code which always will be prone to
  failure. I am not sure whether this is really helpful.

- Apart from that, a lot of our business logic involves working binary
  files on disk, especially in terms of auto-creating large (think
  of 10 meg sized xls or OpenOffice files) spreadsheets where "works
  well" is defined by knowing that (a) the right data is in the right
  places and (b) the formatting / style of the output is as should be.
  The logic used to create those seems to have grown throughout the last
  years and now ended up in a single method of a couple of thousands of
  lines with a dozen of nested if/else layers in the proprietary system
  to output a custom formatted .txt file and a load of VBA macro logic
  in Excel in example to create the spreadsheet. This kind of scenario,
  which happens quite often here (heavy loading/recombining database
  data, heavy loading and especially writing file based data where the
  file structure is complex yet important) is one of my major issues
  as, for that, I don't really have a meaningful idea yet how to handle
  it. My first shot eventually would be to slowly break down those
  "monster methods" to at least cut out things which are I/O, which is
  difficult because even I/O to the file is sprayed all across the
  method itself. I am concerned that any way of touching this file
  might end up breaking everything beyond repair.

Well, maybe after all this ends up being just complaining about
something which is hard to change, and I know rather well that in this
situation tooling won't help (as none is available), yet starting all
over anew also might end up nowhere. What are your shots at such
situations? Any other (strategy, ...) thoughts how to get out of this
somehow? :)

TIA and all the best,
Kristian


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

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/