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.
Martin Fowler, Kent Beck
Users can dramatically improve the design, performance, and manageability of object-oriented code without altering its interfaces or behavior. "Refactoring" shows users exactly how to spot the best opportunities for refactoring and exactly how to do it, step by step.
David Chelimsky, Dave Astels
Behaviour Driven Development is about writing software that matters. It is an approach to agile software development that takes cues from Test Driven Development, Domain Driven Design, and Acceptance Test Driven Planning. RSpec and Cucumber are the leading Behaviour Driven Development tools in Ruby. RSpec supports Test Driven Development in Ruby through the BDD lens, keeping your focus on design and documentation while also supporting thorough testing and quick fault isolation. Cucumber, RSpec's steadfast companion, supports Acceptance Test Driven Planning with business-facing, executable requirements documentation that helps to ensure that you are writing relevant software targeted at real business needs. The RSpec Book will introduce you to RSpec, Cucumber, and a number of other tools that make up the Ruby BDD family. Replete with tutorials and practical examples, the RSpec Book will help you get your BDD on, taking you from executable requirements to working software that is clean, well tested, well documented, flexible and highly maintainable.
Take Ruby development to the next level: leverage Ruby's full power to write more maintainable, manageable, and pleasing applications * *Master object-oriented Ruby techniques for building applications that are as easy to maintain and upgrade as they were to write! *Discover concrete solutions for common issues associated with poorly designed, hard-to-change Ruby applications. *Solves painful problems now facing many of the world's 1+ million Ruby developers, including programmers at all levels of experience. Years after the initial release of Ruby on Rails, the chickens are coming home to roost. Suddenly, anyone could write a web application -- and it seems like everyone did. The web is now awash in Ruby applications that were easy to write but are now virtually impossible to change, extend, or grow. This book solves that problem by teaching developers real-world object oriented design techniques specifically focused on Ruby. Writing for more than 1,000,000 Ruby developers at all levels of experience, Sandi Metz shares knowledge and concrete solutions for creating more extensible, more maintainable applications - and for fixing many of the poorly designed applications they must now manage. The first book to focus squarely on object-oriented Ruby application design, Practical Object Oriented Design in Ruby will guide developers to superior outcomes, even if their previous experience has been strictly limited to 'procedural' techniques. Metz distills a lifetime of conversations about object-oriented design and many years of whiteboard drawings into a set of specific Ruby practices and patterns that lead to more manageable and pleasing code. Novice Ruby programmers will find specific 'rules to live by'; intermediate Ruby programmers will find valuable principles they can flexibly interpret and apply; and advanced Ruby programmers will find a common language they can use to lead development and guide their colleagues.
Ryan Bigg, Yehuda Katz
Rails makes getting an application up and running easy, but how can a developer ensure that it continues to function well? The answer is Test and Behavior-Driven Development. These Agile approaches, combined with the advantages of the latest software version, make Rails 3 a powerful development framework. Rails 3 in Actioncovers developing a Rails 3.0 application from the ground-up using the industry's best practices in an Agile development fashion, tackling one feature at a time in order to build a solid, maintainable and scalable application. A comprehensive and hands-on guide, the authors show readers how to get the most out of Rails, including tips on leveraging the treasure-trove of community-provided code available.
Bridging the Communication Gap is a book about improving communication between customers, business analysts, developers and testers on software projects, especially by using specification by example and agile acceptance testing. These two key emerging software development practices can significantly improve the chances of success of a software project. They ensure that all project participants speak the same language, and build a shared and consistent understanding of the domain. This leads to better specifications, flushes out incorrect assumptions and ensures that functional gaps are discovered before the development starts. With these practices in place you can build software that is genuinely fit for purpose.