Software is never done. The world around your program changes faster than you want it to. Frameworks and libraries are abandoned and replaced with something better (or just something new), so you need to migrate. You can postpone this work for a bit, but eventually you'll have to catch up, or your project may end up hopelessly outdated. I'm sure you know one or two of those projects!

How can you make all of this easier for yourself and the future maintainers of the project? The keyword is "decoupling". You can change the design of your code to defend it against changes in any dependency your project relies on. Decoupling your code is a way to make it future-proof (without doing too much work that "you ain't gonna need").

About 10 years ago I started looking for ways to decouple my code, but at first I struggled to do it effectively. My code was decoupled in the wrong places, or in the wrong way. I got a better view on this topic after several intense experiences with some legacy projects, a big framework migration, and a complete project rewrite (that I'm sure could have been prevented). I've collected many recipes for decoupling along the way. This book gives you a practical overview of common situations that suffer from an often unintended high level of coupling in web applications. Of course, it also gives you step-by-step recipes to improve these situations.

The examples in this book show you how to decouple from your:

• Web framework
• Templating engine
• Test framework
• Mocking library
• ORM and database
• Queueing server
• (and so on)