Understanding the Four Rules of Simple Design (The Book, Single Copy License)
Last updated on 2014-06-04
About the Book
Check out some feedback from readers.
Modern software development is a game of ever-increasing frequency of change. This is why it is imperative to build systems that are flexible and can adapt to changing requirements, both expected and (more often) unexpected. That is why I've written this book.
From 2009 to 2014, I traveled the world working with software developers, both individually and in teams, to improve their craft. Primarily, I did this through a training workshop format called coderetreat. Over those years, I had the opportunity to watch 1000's of pairs of programmers work on exactly the same system, Conway's Game of Life. As time progressed, I began to see patterns arise. I noticed common techniques and designs that spanned languages and companies and crossed national borders.
As co-founder and a facilitator of coderetreat workshops, I had the unique opportunity to provide feedback, both direct and through questions, on improving the act of writing adaptable, simple code. Through the day, we worked on improving our ability to make good choices around the minute-by-minute decisions made while writing code.
This book is about those things I learned from watching these 1000's of pairs working on the same problem. It contains a large part of the feedback that I provide during a typical coderetreat. The primary focus is on the thought process behind refactoring, and how that is influenced by the 4 rules of simple design.
This book is not about Conway's Game of Life. Instead, it uses its domain as a backdrop to discuss the thoughts and ideas behind the 4 rules of simple design. It focuses on the small decisions made while designing your code with the goal of building robust, adaptable codebases that can stand the test of time.
With forewords by Joe Rainsberger and Kent Beck.
Curious what the book is like?
I've put together a free downloadable sample of the book with one of the examples (having test names influence the api) and a section on the ping-pong pair-programming style.
The Book, Single Copy License
The Book, 10-Copy License
Use this to purchase a licenses for 10 copies of the book at a discounted rate! Great for classes, workshops and companies.
The Book, 50-Copy License
- Foreword: Kent Beck
- Foreword: Joe Rainsberger
- Who It Is For
- What It Is (And Isn’t) About
- Why Ruby?
Where do these thoughts come from?
- Good Design?
- Conway’s Game of Life
- 4 Rules of Simple Design
- Test Names Should Influence Object’s API
- Duplication of Knowledge about Topology
- Behavior Attractors
- Testing State vs Testing Behavior
- Don’t Have Tests Depend on Previous Tests
- Breaking Abstraction Level
- Naive Duplication
- Procedural Polymorphism
- Making Assumptions About Usage
- Unwrapping an Object
- Inverted Composition as a Replacement for Inheritance
Other Good Stuff
- Other Design Guidelines
- Example constraints
Some Thoughts On Pair-Programming Styles
- Ping-Pong Pairing
- Which Style Should You Choose?
- 4 Rules of Simple Design
- General Design
- Other Things You Probably Should Most Definitely Read
The Leanpub 45-day 100% Happiness Guarantee
Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms...