Mike Spille
Posts: 25
Nickname: mspille
Registered: Nov, 2002
|
|
Re: Design Principles and Code Ownership
|
Posted: Dec 4, 2002 7:25 PM
|
|
> > I'm forced to completely disagree. One given instance
> of
> > an explicit piece of code is easier to understand. "N"
> > instances of code 99% the same is not easier to
> understand
> > - even it's only three instances - because to
> understand
> > the whole mechanism you have to look at all the
> > instances.
> >
> That's true, but I don't think that's the kind of
> "explicitness" we are talking about. Perhaps you have
> three methods whose names each explicitly say what they
> do. That makes code calling them more explicit. But if
> those methods do 99% of the same thing, then they that 99%
> code should be factored out as one private helper method
> (also with an explicit name). Now it is a judgement call
> whether to collapse the three public methods into one
> public method with a parameter. The point of the
> explicitness argument I think is simply that part of the
> way you make that judgement is by asking yourself what
> appoach (three methods versus one) will make the client's
> code easiest to read and understand, and that method names
> that explicitly say what they do tend to improve
> readibility.
>
I concur completely in those areas. I think part of the mismatch is not based on the interview, but one of the supporting documents (Mr. Fowler's essay on explicitness). In that document the view is very much (and this is a paraphrase, not a direct quote) "do exactly what the user story says, do not extrapolate, and make it as concrete as possible". The last example given is the discount plan example, and I disagree most heartily with that example. There, the discussion is about a common business component (discount plans), of which there are several variations (in the example, three). In that sort of situation the explicit code is a cop out. You're making someone's life more difficult down the road on purpose so you can get this iteration in with minimal work. I think that's wrong - not morally, but in terms of overall work on a project. In short, the coder is just _asking_ for trouble by being explicit in that sort of situation.
> > Worse - you've still overlooked the cost and effort of
> > programmer time. Explicit solutions always need a
> > developer to make any sort of change. That's not only
> > inflexible, but expensive. In NYC, where I work,
> > developers routinely get 6 figures or just below. The
> > last person I want fiddling with a discount rate is a
> > programmer.
> >
> I wouldn't equate explicit with non-configurable. You can
> have a highly configurable system from the outside whose
> code on the inside is explicit. Explicit doesn't mean you
> don't use data. It just meanst that when I look at your
> code it kind of tells me what it does by the way you've
> partitioned things and named them.
I don't think that's so much as explicit as just plain well written. If you re-read Mr. Fowler's essay I think you'll see that he's directly arguing against data-driven code unless a powerful argument is made for it. Explicit there means very, very explicit, to the point of hard-coding your discount rate for the "blue plan" (or whatever) directly in your code at 15%. Perhaps the example was just a really bad one from my perspective, having seen precisely such code push projects past deadlines and over budget because someone took a very, very short term view of the requirements.
It's even worse in the XP sense. Given rotating pair programmers working on different stories at different times, the developer is in effect foisting the effort to make the code configurable on some other developer at a later time - when the system is more complex and by definition harder to refactor. See the essay by Mr. Fowler's company which dissects a large project which took the XP approach, and how following requirements literally at every stage got them in to trouble.
The problem I really have with this flavor of expclitness is the concept of religiously following the requirements of this iteration (possibly out of many, many iterations) and refusing to apply any forsight at all. Mr. Fowler can assert all he wants that it works out somehow in the end, but real case studies say precisely the opposite.
-Mike
|
|
Previous Topic
