Agile Technical Practices Distilled
Agile Technical Practices Distilled
A Journey Toward Mastering Software Design
About the Book
The authors of the book have been working as software developers and coaches for years, accumulating more then half a century of experience. During this period working in the trenches of teaching software design we created lots of content and shared many stories of real professional life among us. From the feedback we had, we thought it would be a good idea to organize all the information in a single place, following a logical sequence, creating a sort of learning journey. We touch all the principles we consider important to master, dropping too many details. In our profession the information are far too many to be all memorized, let alone mastered. The ability to select what to focus on is maybe more important then the ability of learning itself. We all are very excited to be able to share with you our personal selection of content and the lessons we learned the hard way. We genuinely hope that at the end of it you will find some new ideas for improving your Software Design skills, the relationship within your team and your business as well.
About the Authors
About the Contributors
Table of Contents
-
Introduction
-
AGILE TECHNICAL PRACTICES
- Is this book for me?
- Why we wrote this book
- Why distilled?
- What are Agile Technical Practices?
- Rules, principles and values
- How this book is organized
- How to get the most out of this book
- Resources
-
AGILE TECHNICAL PRACTICES
-
First steps
-
PAIR PROGRAMMING
- What is pair programming?
- Roles
- Driver/Navigator switch techniques
- Breaks
- Katas
- When should I move to the next chapter?
- Resources
-
CLASSIC TDD I – TEST-DRIVEN DEVELOPMENT
- Classic TDD
- The three laws of TDD
- Refactoring and the Rule of Three – baby steps
- Three methods of moving forward in TDD
- Degrees of freedom
- Naming tests
- A test name pattern
- Katas
- More katas
- Great habits
- Classic TDD flow
- Where are we in the big picture of OO software design?
- When should I move to the next chapter?
- Resources
-
CLASSIC TDD II
- Writing the assertion first and working backward
- Organizing your test in arrange, act and assert blocks
- Unit test principles
- Katas
- Great habits
- Classic TDD flow
- Where are we in the big picture of OO software design?
- When should I move to the next chapter?
- Resources
-
CLASSIC TDD III – TRANSFORMATION PRIORITY PREMISE
- Kata
- TPP – Defining obvious implementation
- Katas
- Great habits
- Classic TDD flow
- Where are we in the big picture of OO software design?
- When should I move to the next chapter?
- Resources
-
DESIGN I – OBJECT CALISTHENICS
- It’s the design…
- Kata
- Object calisthenics – 10 steps for better software design
- Heuristics
- Katas
- Great habits
- Classic TDD flow
- Where are we in the big picture of OO software design?
- When should I move to the next chapter?
- Resources
-
PAIR PROGRAMMING
-
Walking
-
DESIGN II - REFACTORING
- When to refactor (for now)
- Main refactors
- IDE agility (a.k.a. know your shortcuts)
- Kata
- Refactor 80-20 rule
- Refactoring guidelines
- Kata
- Parallel change (or expand, migrate and contract)
- Kata
- Great habits
- When should I move to the next chapter?
- Resources
-
DESIGN III – CODE SMELLS
- Design smells
- Code smells
- Highlighted code smells
- Object calisthenics preventing code smells
- When to refactor (extended for code smells)
- Refactor code smells
- Kata
- Great habits
- Classic TDD flow
- The big picture
- When should I move to the next chapter?
- Resources
-
TEST DOUBLES
- Principles
- Different types of Test Doubles
- Test Doubles guidelines
- Katas
- Great habits
- When should I move to the next chapter?
- Resources
-
TESTING LEGACY CODE
- Breaking dependencies using a seam
- Characterization tests
- Kata
- Golden Master
- Kata
- Approval Tests by Llewellyn Falco
- Revisiting the refactoring guidelines
- Kata
- Conclusions
- Great habits
- When should I move to the next chapter?
- Resources
-
DESIGN IV – DESIGN PATTERNS
- Design patterns advantages
- Design patterns pitfalls
- Quick reference catalogue
- Revisiting the refactoring guidelines
- Kata
- Great habits
- When should I move to the next chapter?
- Resources
-
DESIGN II - REFACTORING
-
Running
-
DESIGN V – COHESION AND COUPLING
- Coupling
- Cohesion
- Katas
- When to refactor (extended for Cohesion/Coupling)
- Classic TDD flow
- The big picture
- When should I move to the next chapter?
- Resources
-
DESIGN VI – SOLID PRINCIPLES++
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
- Balanced Abstraction Principle
- Principle of Least Astonishment (a.k.a. WTF principle)
- Kata
- When to refactor (extended for SOLID principles)
- Classic TDD flow
- The big picture
- When should I move to the next chapter?
- Resources
-
DESIGN VII - CONNASCENCE
- Definition
- Dimensions
- Connascence of Name and Type (CoN and CoT)
- Connascence of Position (CoP)
- Connascence of Value (CoV)
- Connascence of Meaning (or Convention) (CoM)
- Connascence of Algorithm (CoA)
- Connascence of Execution Order (CoEO)
- Connascence of Timing (CoTm)
- Connascence of Identity (CoI)
- Connascence of Manual Task (CoMT)
- Classic TDD flow
- The big picture
- When should I move to the next chapter?
- Resources
-
DESIGN VIII – THE FOUR ELEMENTS OF SIMPLE DESIGN
- What are the four elements of simple design?
- What does each element mean?
- Alternative definitions of simple design
- Our personal definitions of simple design
- Kata
- Classic TDD flow
- The big picture
- When should I move to the next chapter?
- Resources
-
DESIGN IX - CONCLUSION
- Cohesion and Coupling as forces
- The 3 Cs of design: from Cohesion and Coupling to Connascence
- Systems Entropy
- The big picture
- Resources
-
DESIGN V – COHESION AND COUPLING
-
Flying
-
OUTSIDE-IN DEVELOPMENT
- Classic TDD approach
- Acceptance tests
- Test boundaries
- Double loop TDD
- The Outside-In approach
- Outside-In TDD: London school
- The direction of dependencies
- Should I use classic TDD or Outside-In TDD?
- Kata
- The big picture
- Great habits
- Resources
-
BEHAVIOR-DRIVEN DEVELOPMENT (A.K.A. LOVE YOUR REQUIREMENTS)
- Poka-yoke
- Mistakes versus defects: feedback is the cure (again)
- Bugs and communication
- User stories
- Behavior-Driven Development
- Acceptance Tests done right
- Boundaries
- The walking skeleton
- Kata
- Resources
-
UNDERSTAND THE BUSINESS
- Knowledge versus understanding
- Theory of Constraints
- Domain-Driven Design: What domain?
- Beyond requirements: knowledge crunching
- Value stream and domain events
- Bounded contexts and communication
- Business and DevOps
- System Thinking and Sociotechnical organizations
- Resources
-
THE STORY OF TEAM C
- Terraforming
- Team building
- The backlog: crunching knowledge for breakfast
- Cracking on
- From forming to performing
- Outside-In ATDD with optional unit tests
- The green flag
- The moral of the story
-
CONCLUSION
- The human factor
- Team play
- Bounded rationality and knowledge sharing
- Resources
-
OUTSIDE-IN DEVELOPMENT
-
Appendices
- THE 12 AGILE PRINCIPLES
-
PopcornFlow by Claudio Perrone
- The 7-steps decision cycle
- The principles
- Who can benefit from PopcornFlow
- Resources
-
EventStorming by Alberto Brandolini
- Silos and value stream
- The importance of learning
- The EventStorming approach
- The workshop: a quick overview
- Different flavors of EventStorming
- Complex Systems and proven solutions
- Resources
-
License: CyberDojo
- About CyberDojo Foundation exercises
- Web resources
-
SAMPLE SOLUTIONS
- Sample solutions: FizzBuzz in Clojure
- Sample solutions: Fibonacci sequence in C++
- Sample solutions: Roman numerals in C#
- Sample solutions: TicTacToe in Swift (partial solution)
- Sample solutions: Connecting code smells with Cohesion/Coupling
- Sample solutions: Connecting object calisthenics with code smells and Cohesion/Coupling
- Sample solutions: Connecting Cohesion / Coupling and SOLID principles
-
ABOUT THE AUTHORS
- Pedro
- Marco
- Alessandro
- Personalized coaching
- FEEDBACK PLEASE
- Notes
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.
You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!
So, there's no reason not to click the Add to Cart button, is there?
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $14 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
