Purchase from these online retailers:
Below you will find an overview of this book, some key sections from the Introduction, and information about the author.
Write code that can adapt to changes
By applying this book’s principles, you can create code that accommodates new requirements and unforeseen scenarios without significant rewrites. Gary McLean Hall describes Agile best practices, principles, and patterns for designing and writing code that can evolve more quickly and easily, with fewer errors, because it doesn’t impede change.
Now revised, updated, and expanded, Adaptive Code, Second Edition adds indispensable practical insights on Kanban, dependency inversion, and creating reusable abstractions. Drawing on over a decade of Agile consulting and development experience, McLean Hall has updated his best-seller with deeper coverage of unit testing, refactoring, pure dependency injection, and more.
Master powerful new ways to:
- Write code that enables and complements Scrum, Kanban, or any other Agile framework
- Develop code that can survive major changes in requirements
- Plan for adaptability by using dependencies, layering, interfaces, and design patterns
- Perform unit testing and refactoring in tandem, gaining more value from both
- Use the “golden master” technique to make legacy code adaptive
- Build SOLID code with single-responsibility, open/closed, and Liskov substitution principles
- Create smaller interfaces to support more-diverse client and architectural needs
- Leverage dependency injection best practices to improve code adaptability
- Apply dependency inversion with the Stairway pattern, and avoid related anti-patterns
The title of this book, Adaptive Code, is a good description of the outcome of applying the principles in the book: the ability of code to adapt to any new requirement or unforeseen scenario while avoiding significant rework. The aim of this book is to aggregate into one volume many of the current best practices in the world of C# programming with the Microsoft .NET Framework. Although some of the content is covered in other books, those books either focus heavily on theory or are not specific to .NET development.
Programming can be a slow process. If your code is adaptive, you will be able to make changes to it more quickly, more easily, and with fewer errors than you would if you were working with a codebase that impedes changes. Requirements, as every developer knows, are subject to change. How change is managed is a key differentiating factor between successful software projects and those that fail. Developers can react in many ways to requirement changes, with two opposing viewpoints highlighting the continuum that lies between.
First, developers can be rigid. In this approach, from the development process down to class design, the project is as inflexible as if it were implemented 50 years ago by using punch cards. Waterfall methodologies are conspicuous culprits in ensuring that software cannot change freely. Their determination that the phases of analysis, design, implementation, and testing are distinct and one-way make it difficult—or at least expensive—for customers to change requirements after implementation has begun. The code, then, does not need to be built for change: the process all but forbids alterations.
Second, developers can be adaptive. Agile processes are not just an alternative to such rigid methodologies, but a reaction to them. Their aim is to embrace change as a necessary part of the contract between client and developer. If customers want to change something in the product that they are paying for, the temporal and financial cost should be correlated to the size of the change, not the phase of the process that is currently in progress. Unlike physical engineering, software engineering works with a malleable tool: source code. The bricks and mortar that form a house are literally fused together as construction progresses. The expense involved in changing the design of a house is necessarily linked to the completion of the building phase. If the project has not been started —if it is still just in blueprints— change is relatively cheap. If the windows are in, the electricity wired up, and plumbing fitted, moving the upstairs bathroom down next to the kitchen could be prohibitively expensive. With code, moving features around and reworking the navigation of a user interface should not be so significant. Unfortunately, this is not always the case. The temporal cost alone often prohibits such changes. This is largely a result of a lack of adaptability in code.
Who should read this book
This book is intended to bridge a gap between theory and practice. The reader I had in mind while writing this book is a programmer who seeks more practical examples for design patterns, SOLID principles, unit testing and refactoring, and more.
Capable intermediate programmers who want to plug the gaps in their knowledge or have doubts and questions about how some of the industry’s best practices fit together will benefit most from this book, especially because the day-to-day reality of programming rarely matches simple examples or theory. Much of SOLID is now understood, but the intricacies of the open/closed principle (covered in Chapter 8) and Liskov substitution (covered in Chapter 9) are not fully comprehended. Even experienced programmers sometimes do not fully realize the benefits provided by dependency injection (covered in Chapter 12). Similarly, the flexibility—adaptability—that is lent to code by interfaces (covered in Chapter 4) is often overlooked.
There is also plenty of content in this book for the more junior developer to learn, from the ground up, which aspects of common patterns and practices are benevolent and which are, in the long term, problematic. The different codebases that I see while consulting have a lot of problems in common. The general theme is that the code is almost there with respect to adaptability, but it just needs a slight push in the right direction to make it significantly more adaptive to change. Specifically, the Entourage anti-pattern (covered in Chapter 11) and the Service Locator anti-pattern (covered in Chapter 12) are prevalent in the code of stalled projects. Practical alternatives, and their rationales, are provided in this book.
Ideally, you should have some practical experience of programming in a language that is syntactically similar to C# such as Java or C++. You should also have a strong foundation in core procedural programming concepts such as conditional branching, loops, and expressions. You should also have some experience of object-oriented programming concepts using classes. and at least a passing familiarity with interfaces.
This book might not be for you if…
This book might not be for you if you are just starting out on a journey to learn how to program. This book covers advanced topics that assume a thorough understanding of fundamental object-oriented programming concepts, such as classes and interfaces, in addition to control structures such as if-statements and loops.
Changes in the second edition
For readers of the first edition, there are compelling reasons to invest in this updated version:
- A new chapter on Kanban has been added to complement the chapter on Scrum.
- Testing and refactoring now each have their own full chapters so that more content can be covered.
- The dependency inversion chapter has been rewritten to include a section on abstraction design.
- A new chapter on coupling and cohesion has been added.
- The sample code has been updated to C# 7.0 and .NET 4.6.2 in Microsoft Visual Studio 2017.
- All other chapters have had edits and tweaks.
About the Author
GARY MCLEAN HALL lives in Manchester, England, with his wife, daughter, son, and dog.
Gary is an experienced software developer and architect, specializing in patterns and practices. He has worked with numerous Agile teams that have maintained a strong focus on creating code that is adaptive to change. He has worked for companies such as Eidos, Xerox, Nephila Capital Ltd., and The LateRooms Group. In each role, he excelled at balancing the delivery of a software product and the quality of its source code.
Gary is the founder of Igirisu Ltd, a software consultancy, and co-founder and CTO of Dynamic Path Ltd.