Refactoring is a word on every developer’s lips, but not always at their fingertips. Through the Gilded Rose kata, we’ll explore the habits and choices that move us towards (or away from) solutions that match their problem.
We will also see we can reduce much of the pain and churn of software development by viewing it through the lens of refactoring-driven development. Refactoring is not just tidying; it is a design practice and a discovery process.
Refactoring is a word on every developer’s lips, but not always at their fingertips. There is more to refactoring than IDE shortcuts and code tidying. Refactoring is a tool for understanding and improving code by changing it and for revealing and implementing design choices. It is about uncovering possibilities, such as the paradigm that best fits the problem and new ways of thinking about solutions.
Many developers understand refactoring at a more superficial level and often do little more than rename identifiers or extract functions. This session looks to go deeper and to present refactoring as a first-class design practice.
We’ll walk through the classic Gilded Rose refactoring kata — don’t worry if you don’t know it, all will be introduced! — taking it from its initial painfully realistic business logic all the way through a series small changes to a solution that better fits the problem as described and simplifies future changes. We’ll look at what kinds of tests are suitable for the code, we’ll question some common coding habits, we’ll see that neither force-fitting an object-oriented approach nor tackling it just through procedural refactoring gives a good fit solution, and we’ll arrive at a solution that owes more to declarative thinking than imperative.
We will also see we can reduce much of the pain and churn of software development by viewing it through the lens of refactoring-driven development.