They know a lot about their business and so they know all exceptions to all the rules. This leads to overcomplexifying any solution. That leads to paralysis by analysis in some cases too. Since the problem we were using to practice testing was getting in the way again and again (due to corner cases) I decided we would ignore the problem and do a kata instead.
Since I also wanted them to do a kata similar enough to what they were trying to solve I just made one up on the spot and made it so that some problems in the kata were close enough to the actual problem.
DISCLAIMER: I know this intro is extremely vague. Just cut to the chase.
Baggage Collector Kata
Imagine you work at a baggage handling service of a regional airport in 1987. You spend your day taking bags that fall through a slide into a pile of baggage, from the pile to (a) the Hangars, (b) the baggage claim Hall or (c) Lost and Found.
Write the code so that a baggage is sent to the appropriate location:
- a baggage has a label with a FROM and TO
- a baggage whose FROM matches the current airport goes to the HANGARS
- a baggage whose TO matches the current airport goes to the HALL
(Hidden rule)
- all others go to LOST and FOUND
NOTE: The hidden rule was left out on purpose. I expected the team to notice there's cases not covered by the original set of rules and to (1) go ask the business expert (me) about what to do and (2) get a test for those cases.
Moving on to the future
While they were coding, I decided time was a variable to consider so I made it so each year would actually happen in 10 minutes. Meaning I added extra rules every 10 minutes.
Time goes by and the airport is being successful. Management is preparing some changes in order to make the airport an international hub.
Your team is merged with the Hangar's team. You now must:
- send baggages to appropriate HANGAR depending on the TO indicated on the label. That is, you no longer send baggages to HANGAR but you send them to HANGAR-8 or HANGAR-4, etc...
Also, you may start receiving bags that are on transit!
- a bag's label may now have several hops on the itinerary. Send bags to HALL if bag is on the last hop or send them to the appropriate hangar if current airport is on the itinerary.
-if the current airport is not on the itinerary, just move the bag to LOST and FOUND.
The Golden Years
The plan seems to be working and your airport is now an international airport! Kudos!
Here's some more considerations:
- if a bag FROM your airport will go abroad, you must send it to X-Ray and then to the appropriate Hangar
- a bag arriving (our airport is final destination) from a country abroad (original airport) then the bag must go to CUSTOMS and then to the HALL.
NOTE: At this point you can let your imagination flow and add all kinds of rules. For example:
- merge your team with lost-and-found teams so that if you receive a baggage you can re-route (even if you are not on the itinerary), just do it.
- make the hangar-to-flight mapping change during time. If a flight has a very early checkin, make it's baggage to the hangar even thought the plane is still not there or even if there's another plane there.
- remove all bags belonging to JACINTO RAMIREZ (a known drug dealer on Interpol's Most Wanted List)
Head fake
I used the kata as a way to get the team to get used to a set of simple rules changing very quickly. You can only go refactor crazy if your basic functionality is granted.
The original problem was simple and easy enough to reason about so as to dig deep into the possible corner cases it presented. We got into the exception handling quick enough. The message I was trying to pass on was: a simple problem is easy to reason but will surely have unspecified corner cases get your business expert in hand, find those cases quickly. Before you start coding your cathedral, step back and think of a good set of possible inputs and the expected outputs. If you find cases you can't answer to, get back to the business expert.
Also, your business will change soon enough and probably on a direction different than what you expected. Don't try to anticipate the future and keep you design simple and uncoupled so that it accepts change easily.
Cap comentari:
Publica un comentari a l'entrada