Refactoring book club questions

1. 1.

   Fowler distinguishes refactoring (improving structure) from feature development (adding behavior). How well does your team actually separate these in practice?

2. 2.

   Which code smells from the catalog — long methods, duplicate code, divergent change, shotgun surgery — most frequently appear in codebases you've worked on?

3. 3.

   Fowler argues that refactoring without a test suite is reckless. What proportion of your current codebase would you trust enough to refactor safely right now?

4. 4.

   The book implies that clean code is a professional responsibility, not optional housekeeping. Do your organization's incentives make it easy or hard to act on that belief?

5. 5.

   Pick a piece of code from your current work that has a clear code smell. Which refactoring from Fowler's catalog would address it first?

6. 6.

   How do you decide when to refactor now versus later? What factors push you toward 'we'll clean it up later' that rarely result in the cleanup actually happening?

7. 7.

   The second edition replaced Java examples with JavaScript. Does the choice of language matter for the principles Fowler is teaching, or is the catalog genuinely language-agnostic?

8. 8.

   Fowler collaborated with Kent Beck on this book. How much of the discipline he describes comes from test-driven development culture specifically, and would it transfer to teams that don't write tests first?

9. 9.

   What is the relationship between refactoring and architecture? Is improving a method-level code smell a different kind of activity from restructuring the module boundaries of a large system?

10. 10.

    Technical debt is the accumulated cost of shortcuts taken during development. Have you ever inherited a codebase where the debt had become so large that refactoring was effectively impossible? How did that situation resolve?

11. 11.

    The named refactorings in the catalog have become standard vocabulary. Are there moves you use regularly that aren't in the catalog? What would you call them?

12. 12.

    Fowler argues code should be easy to change above all else. What happens to that principle when the cost of change has to be balanced against security, performance, or regulatory compliance?

How to run the discussion

• Pick six to eight, not all of them. An hour of real discussion covers fewer questions than anyone expects, and racing the list is what makes a book club feel like homework.
• Open with what people noticed, not what they concluded. Asking for a verdict first hardens opinions before anyone has heard each other.
• Let the disagreement run. The questions below that split a room are the ones worth the time; the ones everyone answers the same way can be skipped.
• Ask the quiet person a specific question. A direct, narrow question is far easier to answer than an open invitation to contribute.