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.

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.

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?