Aug 25, 2011

Api Design: Key vs Session

During discussion of our new API an question come up, why session is better than a simple key.
Session concept is to have per connection object with details on customer, it's preferences, etc.
Key concept is to have passive key and number of services that uses it.
I came up with following:
Session Key
Holds request specific data Need to hold request specific data in api objects
More agile approach, you can make you session active, have one master instance for actions or session-specific actors Managing class and a collection of keys are needed for two way communication
Visible list of services available You should knew about service existence before use it
It's complex to fake system It's easy to confuse keys
It's subject to update. Please place you thoughts about it.

Aug 21, 2011

Legacy system development

If you're like me, then you probably faced developing new features for legacy systems (system with no test coverage) without full understanding of source. I've done this a couple times, and want to share lessons learnt:

Legacy documentation

There are 3 sources of information about system - experienced colleagues, documentation(if exists, including javadocs and tests) and source. Fact is, you should not trust first two and use them only to understand third.
Colleagues may forget smth or think of it as of obvious thing. Tests, if they exists may be incorrect or deprecated. If documentation isn't a part of delivery, noone bothers keeping it up-to-date.

Development surroundings

Most likely new development will introduce bugs. Mine does. But not in feature you're working on. It will be some other functionality, linked with yours.
So, you need to recheck code you're depending on and recheck code, that depends on your new logic.

Also requirements is important - if you haven't understand them, you will not deliver valuable feature.

Summary

  • Use all information you can get, but dont rely on it
  • Only reliable source of information - code
  • Check and recheck code you're depending on and code that depends on your's code
  • Understand your requirements