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).