A design problem I met again and again.

[Emile van Sebille]

andrew cooke wrote:
> Emile van Sebille wrote:
>>>> Whether you (generic you) choose to do so or not is a separate issue.
>> Also agreed - and that is really my point.  Doing so feels to me like
>> continuing to look for a lost object once you've found it.
> 
> i can see your point here, but there's two things more to consider:
> 
> 1 - if you do need to refactor it later, because there is a bug say, it
> will be harder to do so because you will have forgotten much about the
> code.  

Yes, I generally count on it.  Refactoring at that time is precisely 
when you get the most benefit, as it will concisely focus your 
attentions on the sections of code that need to be clearer to support 
the debugging changes.  Face it, you'll have to get your head around the 
code anyway, be it 1, 5, or 10k lines and all beautifully structured or 
not.  Remember, proper refactoring by definition does not change 
functionality -- so that bug in the code will be there regardless.

> so if it is likely that you will need to refactor in the future, it
> may pay to do some of that work now.

Certainly -- and I envy those who know which sections to apply their 
attentions to and when to stop.  Personally, I stop when it works and 
wait for feedback.

> 2 - if someone else needs to work with the code then the worse state it is
> in - even if it works - the harder time they will have understanding it. 
> which could lead to them using or extending it incorrectly, for example.

Assuming you're talking about non-refactored code when you say worse, 
consider Zope vs Django.  I have no doubt that both meet an acceptable 
level of organization and structure intended in part to facilitate 
maintenance.  I've got multiple deployed projects of each. But I'll hack 
on Django if it doesn't do what I want and I find that easy, while 
hacking on Zope ranks somewhere behind having my mother-in-law come for 
a three-week stay on my favorite-things-to-do list.  Refactored code 
doesn't necessarily relate to easier understanding.

> both of the above fall under the idea that code isn't just a machine that
> produces a result, but also serves as documentation.  and working code
> isn't necessarily good documentation.

Here I agree.  Once I've got it working and I have the time I will add 
minor clean up and some notes to help me the next time I'm in there. 
Clean up typically consists of dumping unused cruft, relocating imports 
to the top, and adding a couple lines of overview comments.  On the 
other hand, I do agree with Aahz's sometimes tag line quote accepting 
all comments in code as lies.  It's akin to believing a user -- do so 
only at your own peril.  They're really bad witnesses.

> i don't think there's a clear, fixed answer to this (i don't think "stop
> refactoring as soon as all tests work" can be a reliable general rule any
> more than "refactor until it is the most beautiful code in the world" can
> be).  you need to use your judgement on a case-by-case basis.

Well said.

> in fact, the thing i am most sure of in this thread is that 15000 lines of
> code in one module is a disaster.  

Agreed.  I took a quick scan and the largest modules I'm working with 
look to be closer to 1500 lines.  Except tiddlywiki of course, which 
comes in at 9425 lines in the current download before adding anything to 
it.  I bet I'd prefer even hacking that to zope though.

One programmer's disaster is another programmer's refactoring dream :)

Emile