+972 52-548-6969
The small difference between OK Code and Good Code
time to read 1 min | 130 words
This is OK code:
def LockItem(itemKey as string): while true: result = PUT( "lock of "+itemKey, "requiredValue" ) break if result is SuccessfulUpdate // we don't sleep, the remote call take care of spacing the calls in time
And this is good code:
def LockItem(itemKey as string): while true: result = PUT( "lock of "+itemKey, clientName ) break if result is SuccessfulUpdate // we don't sleep, the remote call take care of spacing the calls in time
The only difference is with the value we set, and that is never used by the application.
Why is this important?
Comments
Locks per client instead of globally?
Nope, the value of the lock has no meaning to the app whatsoever.
See the previous post about the details of the locking scheme
I guess the only thing i can think of is that if you were to inspect the state of the cache the clientName might help you track down a bug?
Yes!
The major difference here is that one approach is a dead end when you troubleshoot.
The second approach give you much more insight into what is going on
Interesting. This points to something that I've mentioned to other people before, but no one seems to get it. I call it, "coding for debugability". In other words, I'm accepting there there are going to be bugs. The key is to make it so that finding and fixing those bugs is not difficult. Is it a new idea? Probably not. But it's one that has helped me out quite a lot.
Clarify "clientName" : is it the business paying your bill, or the process calling this one?
Current machine name + current instance name.
No mater how good it is, it can always be better - especially if people don't understand the intention here, and why one is better than the other.
Comment preview