Sun, 15 May 2005
Expert code
I've been working on the chapter in Scripting for Testers
where readers start defining classes. As the story behind
the
following text begins, I have to figure out how to make a failing
test pass.
Here's a thought about a solution: After pushing the
new context line
onto potential_context, I could check
if it's too long. If so, I should shorten it. That would look
like this:
def unusual_lines(line_array)
return_value = []
potential_context = []
line_array.each { | one_line |
if unusual?(one_line)
return_value += potential_context
potential_context = []
return_value.push(one_line)
else
potential_context.push(one_line)
potential_context.shift if potential_context.length > 5
end
}
return_value
end
It would pass the test, but am I happy with it?
No. I fear
if statements. I especially
fear if
statements within other if
statements. They're too hard to get right and too confusing to
read. Fortunately, there are
often ways to
set things up so that the code would always make the same decision---and
hence doesn't need an if. Here, there are two
possibilities: make it so that the code always throws away
the first element or such that it never has to throw
away any element.
When I thought about it that way, I realized that if
potential_context always had five
elements, the code would always shift the first one away...
Then there's text on how to make that work. I'm teaching an old
idea:
replace explicit runtime decisions with appropriate setup.
Just after writing that, I flashed on something that Gary Klein
writes in Sources of Power. His research group was preparing to
interview expert firefighters about their decision-making.
We
asked the commander to tell us about some difficult decisions he
had made.
"I don't make decisions," he announced to his startled
listeners. "I don't remember when I've ever made a decision." [...]
He agreed there were options, yet it was usually obvious what to
do in any given situation. He insisted he never [compared
options]. There just was no time. (pp. 11-12)
It was not that the commanders were refusing to compare
options; rather, they did not have to compare
options. [...] [They] could come up with a good course of action
right from the start. [...] Even faced with a complex situation,
the commanders would see it as familiar and know how to react.
The commanders' secret was that their experience let them see a
situation, even a nonroutine one, as an example of a prototype, so
they knew the typical course of action right away. (p. 17)
[T]here are times for deliberating about options. Usually
these are times when experience is inadequate and logical thinking
is a substitute for recognizing a situation as typical. [...]
Deliberating about options makes a lot of sense for novices [...]
(p. 23)
What makes someone an expert is the ability to act
appropriately without resorting to conventional rational
thought, except perhaps for after-the-fact explanations. (And as
both Sources of Power and oodles of old work in expert
systems show, experts often find it difficult or impossible to explain
the reasons behind their actions, even to themselves.)
If the parallel isn't completely bogus, expert code will have
few if statements and be hard to debug.
## Posted at 16:14 in category /coding
[permalink]
[top]
|
