Feathers M. Working Effectively with Legacy Code

Pearson Education, Inc., 2004. — 456 p.Get more out of your legacy systems: more performance, functionality, reliability, and manageability
Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.In this book, Michael Feathers offers start-to-finish strategies for working more effectively with large, untested legacy code bases. This book draws on material Michael created for his renowned Object Mentor seminars: techniques Michael has used in mentoring to help hundreds of developers, technical managers, and testers bring their legacy systems under control.The topics covered include:
Understanding the mechanics of software change: adding features, fixing bugs, improving the design, optimizing performance
Getting legacy code into a test harness
Writing tests that protect you against introducing new problems
Techniques that can be used with any language or platform with examples in Java, C++, C, and C#
Accurately identifying where code changes need to be made
Coping with legacy systems that aren't object-oriented
Handling applications that don't seem to have any structureThis book also includes a catalog of twenty-four dependency-breaking techniques that help you work with program elements in isolation and make safer changes.The Mechanics of Change
Changing Software
Working with Feedback
Sensing and Separation
The Seam Model
ToolsChanging Software
I Don't Have Much Time I Have to Change It
It Takes Forever to Make a Change
How Do I Add a Feature
I Can't Get This Class into a Test Harness
I Can't Run This Method in a Test Harness
I Need to Make a Change. What Methods Should I Test?
I Need to Make Many Changes in One Area
I Need to Make a Change, but I Don't Know What Test to Write
Dependencies on Libraries Are Killing Me
My Application Is All API Calls
I Don't Understand the Code Well Enough to Change It
My Application Has No Structure
My Test Is in the Way
My Project Is Not Object Oriented. How Do I Make Safe Changes?
This Class Is Too Big and I Don't Want It to Get Any Bigger
I'm Changing the Same Code All Over the Place
I Need to Change a Monster Method and I Can't Write Tests for It
How Do I Know That I'm Not Breaking Anything?
We Feel Overwhelmed. It Isn't Going to Get Any BetterDependency-Breaking Techniques
Dependency-Breaking Techniques