How we did it:
For any feedback, any questions, any notes or just for chat - feel free to follow us on social networks
Michael C. Feathers
The average book on Agile software development describes a fairyland of greenfield projects, with wall-to-wall tests that run after every few edits, and clean & simple source code.
The average software project, in our industry, was written under some aspect of code-and-fix, and without automated unit tests. And we can't just throw this code away; it represents a significant effort debugging and maintaining. It contains many latent requirements decisions. Just as Agile processes are incremental, Agile adoption must be incremental too. No more throwing away code just because it looked at us funny.
Mike begins his book with a very diplomatic definition of "Legacy". I'l skip ahead to the undiplomatic version: Legacy code is code without unit tests.
Before cleaning that code up, and before adding new features and removing bugs, such code must be de-legacified. It needs unit tests.
To add unit tests, you must change the code. To change the code, you need unit tests to show how safe your change was.
The core of the book is a cookbook of recipes to conduct various careful attacks. Each presents a particular problem, and a relatively safe way to migrate the code towards tests.
Code undergoing this migration will begin to experience the benefits of unit tests, and these benefits will incrementally make new tests easier to write. These efforts will make aspects of a legacy codebase easy to change.
It's an unfortunate commentary on the state of our programming industry how much we need this book.
Stanley B. Lippman
There is a lot of misinformation and myth about the overhead and costs associated with C++. Now Stan Lippman, the acclaimed author of the C++ Primer, answers the call for a book that gives strategy guidelines for C++ programming. Inside the C++ Object Model explains where overhead costs reside and what they actually consist of. The author explains which parts vary by implementation and which are invariant. He tells how the various implementation models arose, points out areas where they are likely to evolve, and explains why they are what they are. This book is a must for C++ programmers who want to understand the semantic implications of the C++ object model and how the model affects their programs.