Working Effectively With Legacy Code

Working Effectively With Legacy Code

By Michael C. Feathers

Part 1: The Mechanics of Chanage

Chapter 1: Changing Software

Four primary reasons to change software: adding a feature, fixing a bug, improving the design, optimizing resource usage [gdfqeufoj]

Behavior most important thing about software. Users like it when we add it (corretly), but if we change/remove behavior they depend on, they stop trusting us. [giulskqui]

Refactoring: the act of improving design without changing behavior. [gwerlihqo]

Optimization: functionality stays the same similar to refactoring, but the goal is about some resource used by the program, usually time or memory. [gkrkwekri]

Three different things that are typically changed in a system: structure, functionality, and resource usage. [gdeoafffj]

See charts on page 6. They layout what actually changes when you do things like adding a feature, fixing a bug, refactoring and optimize. [gwpwjfhrf]

Adding features, recactoring, and optimizing all hold existing functionality invariant. [gadjwspkj]

How to preserve existing behavior? Unfortunately it can often be difficult to know how much behavior is at risk when we make our changes. [glejpsolp]

To mitigate risk of breaking previous behavior, ask three questions: 1. what changes do we have to make? 2. How will we know that we've done them correctly? 3. How will we know tht we havne't broken anything? [gfrsdlqhp]

It's tempting to think we can minimize software problems by avoiding them, but unfortunatley, it always catches up with us. [gosfepjwl]

Surely more time and scrutiy will make change safer. Or will it? After all of that scrutiny, will anyone know that they've gotten it right? [ghikaejiw]

Chapter 2: Working with Feedback

Chapter 3: Sensing and Separation

Chapter 4: The Seam Model

Chapter 5: Tools

Part 2: Changing Software

Chapter 6: I Don't Have much Time and I have to Change it

Chapter 7: It takes Forever to Make a Change

Chapter 8: How Do I Add a Feature

Chapter 9: I Can't Get This Class into a Test Harness

Chapter 10: I Can't Run This Method in a Test Harness

Chapter 11: I Need to Make a Change. What Methods Should I Test?

Chapter 12: I need to make Many Changes in One Area

Chapter 13: I need to Make a Change, but I Don't Know What Tests to Write

Chapter 14: Depdendencies on Libraries are Killing Me

Chapter 15: My Application is All API Calls

Chapter 16: I Don't Understand the Code Well Enough to Change it

Chapter 17: My Application has No Structure

Chapter 18: My Test Code Is in the Way

Chapter 19: My Project is Not Object Oriented. How do I Make Safe Changes?

(Paul: I LOL'd at this chapter title. This oughta be good).

Chapter 20: This Class is Too Big and I Don't Want It to Get any Bigger

Chapter 21: I'm Changing the Same Code All Over the Place

Chapter 22: I need to change a Monster Method and I Can't Write Tests for it

Chapter 23: Hwo do I know that I'm Not Breaking Anything?

Chapter 24: We Feel Overwhelmed. It Isn't Going to Get Any Better

Part 3: Dependency-Breaking Techniques

Chapter 25: Dependency Breaking Techniques