Notes from a Study Group

Here are my notes from a series of Study Group meeting where our group was studying Working Effectively with Legacy Code by Michael Feathers. I described the different Study Group roles in an earlier post.


Kickoff Meeting

Introductions: Does everyone know everyone else?
Ice-breaker Question: What do you want to get out of this Study Group?

Time: How long per meeting?
Location: Where can we have our meetings?
Frequency: Shall we meet every 1 or 2 weeks?
Pace: How many pages per meeting? How much time per reading? Do we want to be speedy to get through the material or do we want to go deep?
Focus: To what extent do we want to stick to the text of the reading during our meeting?
Expectations: Is it okay to come to the meeting if you haven’t completed the reading?
Roles: Shall we choose to follow the suggested roles?


Meeting One

Assigned Reading: Preface, Introduction, and Part I (Chapters 1-5).
Assigned Roles: Everyone will take on the role of Discussion Director and Technical Vocabulary Enricher.

Opening questions:

  • Does it make sense to create locked down APIs? For example, final classes and concrete classes hidden behind factories?
  • How does duplicate code affect our ability to preserve existing behavior? To add new behavior?
  • What dependencies in our current code base are going to give us the most problems?

Technical vocabulary:

  • Legacy Code (xvi)
  • Edit and Pray (9)
  • Unit Test (14)
  • The Legacy Code Change Algorithm (18)
  • Sensing and Separation (21)
  • Seams (30)
  • Mock Objects (47)


Meeting Two

Assigned Reading: Chapter 6: I Don’t Have Much Time and I have to Change It and Chapter 7: It Takes Forever to Make a Change.
Assigned Roles: Everyone will take on the role of Discussion Director and Technical Vocabulary Enricher.

Opening questions:

  • Does it make sense to create a Sprout Method or a Sprout Class even when doing so degrades the design?

Technical vocabulary:

  • Sprout Method (59)
  • Sprout Class (63)
  • Wrap Method (67)
  • Wrap Class (71)

Meeting Three

Assigned Reading: Chapter 9: I Can’t Get This Class into a Test Harness. Note: we are skipping Chapter 8: How Do I Add a Feature?.

Assigned Roles: Everyone will take on the role of Discussion Director and Technical Vocabulary Enricher.

Opening questions:

  • How to decide between using Extract Interface and Extract Implementor?
  • Have you ever used the Null Object Pattern? If so, could you illustrate with code or on the whiteboard?
  • Is there any reason to use a Singleton?

Technical vocabulary:

  • Construction Test (107)
  • Pass Null (111)

Technical vocabulary (Dependency-Breaking Techniques):

  • Extract Interface (362)
  • Parameterize Constructor (379)
  • Subclass and Override Method (401)

Meeting Four

Assigned Reading: None.
Assigned Roles: Rick and Igor will take on the role of Code Connector. The plan is to (1) find some code that was recently changed without using techniques from Working Effectively with Legacy Code; (2) bring the original code to our meeting; and (3) work through the same change using techniques from Working Effectively with Legacy Code.


Meeting Five

Assigned Reading: Chapter 10: I Can’t Run This Method in a Test Harness and Chapter 11: I Need to Make a Change. What Methods Should I Test?
Assigned Roles: Everyone will take on the role of Discussion Director and Technical Vocabulary Enricher.

Opening questions:

  • Has anyone caught themselves doing anything differently because of what we’ve learned so far?
  • Does adherence to the Single Responsibility Principle affect testability?
  • Is anyone familiar with the Command/Query Separation design principle? If so, could you explain it to the group?
  • What is Michael Feathers advice on testing private methods?

Technical vocabulary:

  • Skin and Wrap the API (205)
  • Lean on the Compiler (315)

Technical vocabulary (Dependency-Breaking Techniques):

  • Adapt Parameter (326)
  • Expose Static Method (345)

As a group we all felt that the techniques in Chapter 11 were overkill. Rather than discuss that chapter we chose to create a mindmap that captured the costs and benefits of unit testing.

Leave a comment

Your comment