Re: multithreaded cache?
On 24.05.2012 08:11, Lew wrote:
Robert Klemme wrote:
And it is true for a number of other techniques I would consider bread
and
butter tools:
- Ensuring requirements are gathered properly and understood before
starting
to code (and design of course).
True, with provisos.
= Requirements are not fixed. What you should have now is the best
available for now.
But there is a minimum standard: there must be enough information to at
least get an idea of what is to be done. I have seen three sentence
requirements for a feature in a complex system which left engineers
wondering what they are supposed to do.
= "Properly"? "Understood"? There are books on this, but it boils down to:
Your software will be used. By whom? Why? What would annoy them? Don't
do that! What would make them forget the software is there and just get
their job done? Do that!
!
"Proper" is always from the user's standpoint. Not what they say, by the
way, but what they think and feel - really. Behind the bullshit and
self-deception, when they aren't posturing for your benefit and really
are just trying to get their work done. And that's where "understood"
comes in. Give'em what they want, not necessarily what they ask for.
Pretty early in my career I had a quite instructive experience: we were
building a web catalog for a business customer with user management, a
lot of technical data about their products - and of course a link to
their ERP system. They wanted to have a price calculation in that
system which could take several routes depending on the user. They
explained it, I wrote a document which also included an UML activity
diagram of the flow with explanations. We sent it in. They rejected:
"No, it must be completely different." So we sat together. End of the
story: it was exactly what they wanted. So they either did not
understood the document and didn't want to ask - or their own
requirements. :-)
- Testing code _before_ shipping.
Some espouse before even writing it. I say, sure, great idea, when you
make it easy to express my ideas in tests instead of imperative code.
Hmm.
BTW, this being Java, have you guys tried EasyMock? (AndroidMock in
Android Java.) That shtuff rocks. It makes your very code better, not
just tested but idiomatically. Tricky stuff. I'll post about that when I
get back into it. I've discovered a Right Way and a Wrong Way to do
mocks, just like I did with JPA.
Not yet, thank you for the pointer!
- When writing unit tests, making sure to also include tests for critical
values (usually corner cases such as -1, 0, 1, limit, limit - 1, limit
+ 1,
null, "", etc.).
Consider this. No matter what input a module receives, it must achieve a
valid program state in response.
No matter what.
Absolutely!
Coding to this formalism means, for example, that a method can handle
all possible argument values.
public interface Caromer
{
public Fromitz carom(Flamo flame);
}
As Herr Klemme points out, 'null' is one possible input for 'flame'.
Non-'null' is another. Presumably a 'Flamo' has observable state that
distinguishes input values. If the type were 'Integer' or 'int',
Robert's example int values might pertain.
But you cannot give infinite test cases to a unit test. So you pick edge
cases, on both the "happy path" (positive) and "unhappy path" (negative)
scenarios.
Exactly.
- Thinking about the person who must use what you produce, regardless
whether
it's a document, a configuration file layout, a DSL, a class, a
library. It
seems many people in software development are far more concerned with the
inner workings of what they create instead of considering how it will
be used.
Maybe it's easier or it is because making it work takes the largest
part of
coding - still the outcome often is dissatisfying and a little more
thought
upfront goes a long way at avoiding maintenance headaches and worse
things.
...
This can't be so difficult, can it?
You have a fine sense of humor.
Well, the fun disappears when you see the same mistakes made over and
over again and attempts to improve it do not have effects...
It's as easy as empathy, and getting inside the mind of a professional
in a field of which you know little to nothing.
I agree for library API design: that takes a bit of experience to get
right. But when it comes to writing documents I think the rules for
readability are quite straight forward (some universities even have them
in their curriculum): do not start with the details but give the reader
an overview first. Give previews and summaries. Generally watch
document structure. Do not put too much in a single diagram. Things
like that.
Testing certainly helps. Functional tests (as opposed to unit tests) can
and should be part of and produced from requirements. At the user-facing
level you can send test scenarios back as memos of understanding (MoUs)
- what better way to make clear what you understand and how it will play
out?
Good point.
Prototypes count, too. They can meet tests, even. Building a prototype
that meets tests, starting within a day or so of starting, kicks ass for
converging on clarity. Keep it up - every day the prototype runs, works
(up to whatever you've done that day), can be checked out and run in any
directory, by any developer, and run, etc.
And prototypes are a great way to test whether ideas work with low
effort before basing a whole design on an idea.
Add a CI tool like Jenkins to run your tests every time you "git commit"
to "origin/master" (or whatever); you got yourself a one-entity
professional shop.
Jenkins is great. We use it. Broken tests are quickly discovered. :-)
Kind regards
robert
PS: Hey, you managed to sneak in a German word. :-)
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/