

How to refactor 31,000 lines of bad code - edw519
http://basildoncoder.com/blog/2008/03/21/the-pg-wodehouse-method-of-refactoring/

======
dhimes
I'm thinking about a similar problem, but perhaps more daunting. I have a
program which is my first real app. I work alone, it's over 40,000 lines (that
includes comments though). Part was written before I knew very much about
coding, and it's very tempting to try to make it all neat. (I have nested
inner-class messes that are pretty hilarious).

It seems unit testing would be key, but it's problematic in that everything is
private! Getting the bird's-eye view is an intriguing thought, but I'm wonder
how to actually go about the refactoring itself?

I could avoid it, but it seems that I'm already hacking code that itself was a
hack (cuz I didn't know what I was doing). It makes updating and extending a
very time-consuming proposition.

~~~
russgray
Hi,

I'm the author of that article. I actually have a blog post in the works that
addresses your concerns fairly directly, since they are concerns for me too.
Keep an eye out for it. In brief, I recommend you buy a copy of Working
Effectively With Legacy Code immediately, then work to get unit tests in
place. Make sure you have a couple of tests for each public interface in the
system. Once you have rudimentary test coverage, it becomes easier to refactor
things without worrying so much about breakage.

~~~
dhimes
That makes a lot of sense. I'll get the book and look out for the post. But I
was wondering: does it make sense to have classes implement interfaces
specifying public exposure of methods, but contain public methods that are
there only to be accessed by the tests?

That is, the interface specifies a public method getIdentity() that returns an
_identity_ object, but the class has getName(), getIDNumber(), that are public
(so we can test them) but not declared in the interface? Do people do things
like that?

