Refactoring Worked Examples

1. Rounding location is behavior

Two rows (quantity 1, unit price 335 thousandths) each round half up to 34 cents. The baseline sums to 68. Rounding only their aggregate gives 67. At time 9 before deadline 10, the baseline applies 10% off and rounds 61.2 cents to 61. At equality it stays 68. Keep a rational oracle and exact integer implementation separate.

2. A failed iterator leaves an observation

The invoice writes its header, consumes one valid row and then receives an iterator exception. The header remains, the exception propagates, and the clock is never read. Moving the header to the end changes this trace. That may be a useful repair, but cannot be claimed as preservation of this baseline.

3. A typed intermediate changes the first failure

For X 2x, the SKU is absent and the quantity is malformed. Lookup-first raises KeyError for X; eager numeric parsing raises ValueError. Retaining the quantity token in the intermediate record lets the pricing phase preserve precedence. Later validation changes should name which error callers will now observe.

4. Mixed clients reveal split state

An old API writes A to (0,0). A new API reads (0,0). Separate maps return None; one authoritative store returns A. Test the reverse direction and overwrite too. The number of overloads says nothing about state consistency.

5. Timeout is an unknown write outcome

The new provider commits a message, then raises because its acknowledgement was lost. Calling the old provider sends another message. The lab propagates the timeout after one invocation; it cannot infer whether the caller should retry. A real recovery design needs durable evidence at the effect's authority.

Attempt the practice tasks, then consult their separate feedback. Keep the original observation even when you later approve a repair.