Working effectively with legacy code
Author(s)
Bibliographic Information
Working effectively with legacy code
(Robert C. Martin series)
Prentice Hall Professional Technical Reference, c2005
- : pbk
Available at 4 libraries
  Aomori
  Iwate
  Miyagi
  Akita
  Yamagata
  Fukushima
  Ibaraki
  Tochigi
  Gunma
  Saitama
  Chiba
  Tokyo
  Kanagawa
  Niigata
  Toyama
  Ishikawa
  Fukui
  Yamanashi
  Nagano
  Gifu
  Shizuoka
  Aichi
  Mie
  Shiga
  Kyoto
  Osaka
  Hyogo
  Nara
  Wakayama
  Tottori
  Shimane
  Okayama
  Hiroshima
  Yamaguchi
  Tokushima
  Kagawa
  Ehime
  Kochi
  Fukuoka
  Saga
  Nagasaki
  Kumamoto
  Oita
  Miyazaki
  Kagoshima
  Okinawa
  Korea
  China
  Thailand
  United Kingdom
  Germany
  Switzerland
  France
  Belgium
  Netherlands
  Sweden
  Norway
  United States of America
Note
Includes index
Description and Table of Contents
Description
This book provides programmers with the ability to cost effectively handlecommon legacy code problems without having to go through the hugelyexpensive task of rewriting all existing code. It describes a series of practicalstrategies that developers can employ to bring their existing softwareapplications under control. The author provides useful guidance about how touse these strategies when refactoring or making functional changes to codebases. One of the book's key points is that it teaches developers to write teststhat can be used to make sure they are not unintentionally changing theapplication as they optimize it. Examples are provided in Java, C++, and Csharp,and the book assumes that the reader has some knowledge of UMLnotation. Strategies using UML and code in C++ and Java primarily whilelanguage independent advice will be delivered in side bars and appendices forlanguage specific users.
Table of Contents
I. THE MECHANICS OF CHANGE.
1. Changing Software.
2. Working with Feedback.
3. Sensing and Separation.
4. The Seam Model.
5. Tools.
II. CHANGING SOFTWARE.
6. I Don't Have Much Time and I Have To Change It.
7. It Takes Forever To Make a Change.
8. How Do I Add a Feature?
9. I Can't Get This Class into a Test Harness.
10. I Can't Run This Method into a Test Harness.
11. I Need to Make a Change. What Methods Should I Test?
12. I Need to Make Many Changes In One Area Do I Have To Break.
13. I Need To Make a Change but I Don't Know What Tests To Write.
14. Dependencies on Libraries Are Killing Me.
15. My Application Is All API Calls.
16. I Don't Understand the Code Well Enough To Change It.
17. My Application Has No Structure.
18. My Test Code Is in the Way.
19. My Project Is Not Object-Oriented. How Do I Make Safe Changes?
20. This Class Is Too Big and I Don't Want It to Get Any Bigger.
21. I'm Changing The Same Code All Over the Place.
22. I Need To Change a Monster Method and I Can't Write Tests for It.
23. How Do I Know That I'm Not Breaking Anything?
24. We Feel Overwhelmed. It Isn't Going To Get Any Better.
III. DEPENDENCY BREAKING TECHNIQUES.
25. Dependency Breaking Techniques.
Appendix: Refactoring.
Glossary.
by "Nielsen BookData"