Check out the resources for this kata.

The main book for this kata is Joshua Kerievsky's "Refactoring to Patterns".

This kata is based on Emily Bache's version: emilybache/Product-Export-Refactoring-Kata.

1. t-initial-setup
   • This is what we'd find in a legacy code
   • No tests
2. t-tests-in-place
   • System is under test
3. t-test-for-different-tax-calculation
   • Code coverage tool uncovered a different tax calculation algorithm
4. t-first-test-refactoring
   • Test code should also be refactored
5. t-add-lombok-dependency
   • We are Java developers of the modern age
   • Some people will call it poor man's Kotlin. And they'd be right
6. t-classes-lombokified-and-simplified
   • Look at this removed code, oh my, the removed code!
7. t-tax-calculator-under-test
   • Tax calculation is tricky and expensive to break
   • We have to make sure we didn't break anything
8. t-ledger-introduced
   • We finally got our domain expert
   • How would you call something that holds a list of orders?
9. t-ledger-renamed-to-account
   • After further discussions, our domain expert says that it should be an Account.
10. t-tax-calculator-removed
    • But tax calculation is hard, we don't want to lose it!
    • Don't worry, now the Account is responsible for it
11. t-rtp-price-implicit-leaf-extracted
    • Alright, finally we can do the refactoring to a Composite pattern
    • Look at one of the commits
      • It's very small
      • There are a lot of such commits, so Pair Programming may be necessary
12. t-strategy-pattern-in-product
    • Introduction
    • Implementation in StoreEvent
    • That strategy pattern came out of nowhere!
      • But it solved a problem of duplication at that time
      • It turned out not to be useful later, so it was removed
13. t-rtp-refactoring-to-composite-done
    • What a journey that was
    • The design is better, the tests pass after each commit, so we could continuously deliver it to production
    • Better, shorter functions
    • But still not declarative enough
14. t-domain-objects-moved-to-domain-package
    • Wait, why are there xml representations of domain objects in the objects themselves?
    • You can argue that it is the domain of the project, because the project is solely for exporting XML
15. t-rtp-xml-builder-implemented
    • Luckily, we've got some spare time, so we'll make the design even better by implementing the Builder pattern
16. t-rtp-encapsulated-composite-with-builder-in-price
    • Now the design better reflects the intent
    • It's more declarative instead of imperative
17. t-rtp-simplify-price-after-encapsulation-with-builder
    • Further simplification
18. t-rtp-simplify-serialization-in-xml-exporter
    • Further deduplication
19. t-refactored
    • That's much better
    • Thankfully we did it in Pair Programming, because a PR for it would be huge!