Okay, here is a brief description: It can be very hard to make changes in large complicated code bases. When we make changes it's important to know that we are making them one at a time. Too often we think we are changing only one thing but instead we end up changing other things unintentionally: we end up introducing bugs. If we can write tests against old code, we can figure out when its behavior is changing. This helps us to know that we've added new code properly and it also supports us when we refactor. Unfortunately, it's often hard to get tests in place in complicated code. You have to refactor to get tests in place in order to refactor. The book shows you now to safely get tests in place to support your work and start to make the code better.
When you do this often enough you start to see code that doesn't have tests as legacy code. The differences between code bases that have tests and those that don't are so significant in most cases that they swamp most other criteria for good design. When you have tests you can make things better, when you don't, often you don't really know whether you are or not.
Introduces the concept of a SoftwareSeam
. See also FeatureDiagrams
WEWLC is a fantastic book. Right up there with RefactoringBook
. Thanks for writing it. -- BillDehora
I'm in the middle of reading this book. Many things are starting to click now, such as how to create good code and refactor legacy code to be easily tested. -- BrianTakita
I found this book very helpful when I was trying to apply TestDrivenDevelopment
to a body of existing code. I was getting quite frustrated. Most of the TDD examples show how to develop new code and tests simultaneously, which is very different from writing tests for existing code. This book made the difference clear and suggested a variety of techniques for coping with the situation. Please note that Feathers defines the term LegacyCode
to mean code that has no UnitTest
s, not to mean "dusty deck" FortranLanguage
code, or binary code for which the source code has been lost, as is used elsewhere. -- StuartMarks
Sometimes a page will end mid-sentence but not be continued on the next page, and other times the sentence will end on one page but the next page starts mid-sentence. It makes it a frustrating read which is a shame because the content of the book is great.
There was also a table that was repeated across a page boundary very early in the book. -- CraigPardey?
Craig, which printing do you have? I don't see any of those errors in the first printing. -- MichaelFeathers
Seventh printing, Jan 2008 -- page 58-59 isn't missing text, it's duplicated; end of page 58 is: "Take a look at Chapter 16, I Don't Understand The Code Well Enough to Change It, for details. When you don't really know how long it is going to take to add a". The start of page 59 is "look at Chapter 16, I Don't Understand...."
End of page 68 is "They just make their call, and everything works out okay." End of this sentence, fine -- but the start of page 69 is "to add behaviour to existing calls of the original method" -- something's gone missing between the two.
The missing text on page 69:
- "This is one form of WrapMethod?. We create a method with the name of the original method and have it delegate to our old code. We use this when we want to add behavior to existing calls of the original method. If every time a client calls pay() we want logging to occur, this technique can be very useful."
The repeated table is at the bottom of page 6 / top of page 7, the "adding feature/fixing bug/refactoring/optimising" one appears twice.
[2010-August-19] In the 10th printing (May 2009) I can confirm the two errors mentioned above -- HG
[2011-January-02] In the 11th printing (May 2010) I can confirm the three errors mentioned above -- Anders Schau Knatten (anders AT knatten DOT org)
[2011-February-23] In the 11th printing (May 2010): At the bottom of page 237, the code should probably say "free(command)", not "free(message)". Also, page 306 begins mid-sentence, out of context: "will need to be refactored". -- Anders Schau Knatten (anders AT knatten DOT org)
The missing text on page 306:
- "Chances are, you will, too. I skeletonize when I feel that the control will need to be refactored after it is clarified."
[2011-March-22] My comment 2011-February-23 regarding the 11th printing is also valid for the 10th printing. -- Anders Schau Knatten (anders AT knatten DOT org)
[2011-April-13] The 12th printing (March 2011) has the same problems on page 6, 59, and 69. These problems haven't been fixed in 3 years. Why doesn't this book have a proper errata page? I like the book but please use a competent publisher/editor next time! They even misspelled their website on the first page of the book (www.prenhallpofessional.com). -- DF
I somehow ended up with an old edition (sixth), but in addition to the table on page 6 repeating on page 7, the sentence at the end of page 5 is never completed; presumably the rest of the paragraph started on page 5 is around the length of the table. I figured it was just because I have an old edition, so I went looking for an errata page and here I am...
[2011-December-14] The 12th printing (March 2011) also has the same uncompleted sentence/paragraph on page 5. -- JTS
[2012-February-15] The 12th printing (March 2011) also has the same errors on page 237 and page 306 mentioned by Anders Schau Knatten on 2011-February-23. -- JTS
[2013-January-09] The 13th printing (December 2011) has similar problems. I'm up to the missing text on page 69. -- TA
[2013-October-21] I can confirm all the above (including the website error) in the 14th printing, as well. I second the concern about the lack of errata page... -- Jon Scharff (jswolf19 at hotmail dot com)
[2014-February-03] In the 14th printing the text in the grey box on pp. 350 states "C++ does not allow virtual function calls to resolve to functions in derived classes." when discussing the Extract and Override Factory Method
. Presumably it should be qualified that C++ prohibits this in constructors. -- WRL