GildedRose-Java
A lesson-by-lesson Java implementation of the Gilded Rose refactoring kata, introduced in 2011 by Terry Hughes and Bobby Johnson using C# and popularized in numerous languages by Emily Bache.
System Requirements
- Java 8 or above
- JUnit 4 (Emily Bache's Java version uses JUnit 5, which has been around since 2016, but most of my enterprise clients have not yet upgraded from JUnit 4)
- Maven
Part I: Underlying Principles
The Four Rules of Simple Design
Any discussion of refactoring begins with the Four Rules of Simple Design, introduced by Kent Beck and restated by Martin Fowler and Corey Haines.
- Passes the tests -- Refactoring, by definition, is changing the structure of your code while maintaining the behavior. A GREEN test run verifies the maintenance of behavior and is therefore a prerequisite to any refactoring.
- Reveals intent -- Code should be self-documenting. My colleague Junilu Lacar expresses this rule by the mnemonic CLEAR (Code Listens Exactly As it Reads).
- No duplication -- Dave Thomas expresses this rule with the mnemonic DRY (Don't Repeat Yourself), and he emphasizes that every bit of knowledge within the system be represented once and only once. The opposite of DRY is WET (Write Everything Twice, We Enjoy Typing, Waste Everyone's Time).
- Fewest elements (Keep it Small) -- As explained by Fowler, any element (class, method, variable) of code that does not serve one of the first three rules should be discarded.
One fantastic team that I coached devised a mnemonic for the last three of these rules: Express your intent with a dry kiss.
Every refactoring action should serve at least one of these rules (or, more specifically, should serve Rule #1 along with at least one of the other three).
eXtreme Programming taught us that tests are "first class citizens." Therefore, our test code, like our production code, is driven by these four rules. Note that achieving expressive test code involves a unique set of techniques.
SOLID Principles
Bob Martin taught us the SOLID Principles of Object-Oriented Design. The first two of these principles are especially relevant to this kata:
- Single Responsibility Principle (SRP) -- A class does one and only one thing
- Open-Closed Principle (OCP) -- A module is open to extension and closed to modification
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
TDD versus Legacy Rescue
Agile software development involves two processes, Test-Driven Development (TDD) and Legacy Rescue. As both processes involve refactoring, both are driven by the Four Rules of Simple Design. The difference lies in the goals of refactoring.
- In TDD, you are refactoring at every green juncture. Strive for perfection.
- In Legacy Rescue, you can't afford perfection. In the words of Arlo Belshee, "Good is too expensive. I just want better (quickly)."
Introduction to Gilded Rose kata
The Gilded Rose Kata begins with a requirements specification and a gnarly, one-method codebase that looks all too familiar to developers. The requirements specification includes one new requirement to be implemented:
We have recently signed a supplier of conjured items. This requires an update to our system:
- "Conjured" items degrade in Quality twice as fast as normal items
The requirement appears simple. Yet the code is so obfuscated that we dare not change it for fear of breaking something. So our adventure begins.