book

Agile Technical Practices Distilled

Name: Agile Technical Practices Distilled
ISBN: 9781838980849

by Pedro M. Santos, Marco Consolaro, Alessandro Di Gioia

June 2019

Intermediate to advanced

442 pages

7h 2m

English

Packt Publishing

Read now

Unlock full access

Preface
About the BookAbout the AuthorsLearning ObjectivesApproachAudienceAcknowledgementsPedroMarcoAlessandroConventionsAgile Technical PracticesIs This Book for Me?Why We Wrote This Book?Why Distilled?What are Agile Technical Practices?Pair ProgrammingTest-Driven Development TDDDesign Improvements/RefactoringSimple DesignBeyond DesignRules, Principles, and ValuesHow Rules Can Lead to Intellectual LazinessUse Rules as a Shortcut to Internalize PrinciplesHow This Book Is OrganizedHow to Get the Most out of This BookAsking for Help or FeedbackHelping OthersFeedback about This BookResources
Section 1
First StepsChapter 1Pair ProgrammingWhat is Pair Programming?RolesDriver/Navigator Switch TechniquesChess ClockPing Pong/PopcornBreaksPomodoroKatasWhen Should I Move to the Next Lesson?ResourcesWeb
Chapter 2
Classic TDD I – Test-Driven DevelopmentClassic TDDThe Three Laws of TDD1. You Are Not Allowed to Write Any More of a Unit Test That Is Sufficient to Fail, and Compilation Failures Are Failures2. You Are Not Allowed to Write Any Production Code Unless It Is to Make a Failing Unit Test Pass3. You Are Not Allowed to Write Any More Production Code That Is Sufficient to Pass the One Failing Unit TestRefactoring and the Rule of Three – Baby StepsThree Methods of Moving Forward in TDDFrom Red to GreenDegrees of FreedomNaming TestsA Test Name PatternKatasFizz Buzz by cyber-dojoFizz Buzz Kata SummaryMore KatasLeap Year by cyber-dojoNth Fibonacci by cyber-dojoGreat HabitsConsiderations when Writing a New TestConsiderations When Making a Failing Test PassConsiderations After the Test PassesClassic TDD FlowWhere are We in the Big Picture of Object-Oriented (OO) Software Design?When Should I Move to the Next Lesson?ResourcesWebBooks
Chapter 3
Classic TDD IIWriting the Assertion First and Working BackwardOrganizing Your Test in Arrange, Act, and Assert BlocksBenefits of Organizing Tests in Arrange, Act, and Assert BlocksUnit Test PrinciplesKatasStats Calculator by cyber-dojoAnagrams by cyber-dojoGreat HabitsConsiderations when Writing a New TestConsiderations when Making a Failing Test PassConsiderations after the Test PassesClassic TDD FlowWhere are we in the Big Picture of Object-Oriented (OO) Software Design?When Should I Move to the Next Lesson?ResourcesWebBooks
Chapter 4
Classic TDD III – Transformation Priority PremiseKataRoman Numerals by cyber-dojoTPP – Defining Obvious ImplementationTPP TableThe TransformationsTransformation 1 – {} -> NilTransformation 2 – Nil -> ConstantTransformation 3 – Constant -> Constant+Transformation 4 – Constant -> ScalarTransformation 5 – Statement -> StatementsTransformation 6 – Unconditional -> ConditionalTransformation 7 – Scalar -> ArrayTransformation 8 – Array -> ContainerTransformation 9 – Statement -> Tail RecursionTransformation 10 – If -> LoopTransformation 11 – Statement -> RecursionTransformation 12 – Expression -> FunctionTransformation 13 – Variable -> MutationExample Using the TPP on the Fibonacci SequenceKatasRoman Numerals by cyber-dojoPrime Factors by cyber-dojoBoolean Calculator by Alessandro Di GioiaGreat HabitsConsiderations when Writing a New TestConsiderations when Making a Failing Test PassConsiderations after the Test PassesClassic TDD flowWhere are We in the Big Picture of Object-Oriented (OO) Software Design?When Should I Move to the Next Lesson?ResourcesWeb
Chapter 5
Design 1 – Object CalisthenicsIt's the Design...KataTic-Tac-ToeObject Calisthenics – 10 Steps to Better Software DesignOnly One Level of Indentation per MethodDon't Use the ELSE KeywordWrap All Primitives and StringsFirst-Class CollectionsNo Getters/Setters/PropertiesWrap All Primitives and StringsOne Dot per LineDon't AbbreviateKeep All Entities SmallNo Classes with More Than Two Instance VariablesAll Classes Must Have StateHeuristicsKatasTic-Tac-ToeGame of LifeGreat HabitsConsiderations When Writing a New TestConsiderations When Making a Failing Test PassConsiderations after the Test PassesClassic TDD flowWhere Are We in the Big Picture of OO Software Design?When Should I Move on to the Next Lesson?ResourcesWeb
Section 2
WalkingChapter 6Design 2 – RefactoringWhen to Refactor (For Now)Main RefactorsIDE Agility (Know Your Shortcuts)KataRefactoring GolfRefactor 80-20 RuleRefactoring GuidelinesStay in the Green While RefactoringCommit as Often as PossibleRefactor Readability before DesignChange Design (Simple Changes)KataTennis Refactoring by Emily BacheParallel Change (Or Expand, Migrate, and Contract)ExpandMigrateContractKataParallel Change Kata by Pawel Duda and Carlos BléGreat HabitsConsiderations When Writing a New TestConsiderations When Making a Failing Test PassConsiderations after the Test PassesWhen Should I Move on to the Next Lesson?ResourcesWebBooks
Chapter 7
Design 3 – Code SmellsDesign SmellsCode SmellsBloatersCouplersObject-Orientation AbusersChange PreventersDispensablesHighlighted Code SmellsCode Smells HierarchyPrimitive ObsessionFeature EnvyMessage ChainsObject Calisthenics Preventing Code SmellsWhen to Refactor (Extended for Code Smells)Refactor Code SmellsKataSmelly Tic-Tac-ToeGreat HabitsConsiderations When Writing a New TestConsiderations When Making a Failing Test PassConsiderations After the Test PassesClassic TDD FlowThe Big PictureWhen Should I Move on to the Next Lesson?ResourcesWebBooks
Chapter 8
Test DoublesPrinciplesCommand-Query SeparationQueriesCommandsDifferent Types of Test DoublesDummy ObjectsStubsFake ObjectsMocksSpiesTest Doubles GuidelinesOnly Use Test Doubles for Classes That You OwnVerify as Little as Possible in a TestDon't Use Test Doubles for Isolated ObjectsDon't Add Behavior in Test DoublesOnly Use Test Doubles for Your Immediate NeighborsToo Many Test DoublesCQS Principle Trade-OﬀSKatasCharacter Copier by Urs EnzlerInstrument Processor by Urs EnzlerGreat HabitsConsiderations When Writing a New TestConsiderations When Making a Failing Test PassConsiderations after the Test PassesWhen Should I Move on to the Next Lesson?ResourcesWebBooks
Chapter 9
Testing Legacy CodeBreaking Dependencies Using a SeamUsing Inheritance to Decouple Production CodeCharacterization TestsKataCharacterization Tests on Gilded Rose Kata by Emily BacheGolden MasterFeasibilityGenerate Input/Output (Golden Master)AssertKataGolden Master on Gilded Rose Kata by Emily BacheApproval Tests by Llewellyn FalcoCombination TestsRevisiting the Refactoring GuidelinesStay in the Green while RefactoringKataGilded Rose Refactoring Kata by Emily BacheConclusionsGuideline QuestionsGreat HabitsConsiderations when Writing a New TestConsiderations when Making a Failing Test PassConsiderations after the Test PassesWhen Should I Move to the Next Lesson?ResourcesWebBooks

Chapter 10
Design IV –Design PatternsDesign Pattern AdvantagesDesign Pattern PitfallsA Quick Reference CatalogueCreational Design PatternsBehavioral Design PatternsStructural Design PatternsRevisiting the Refactoring GuidelinesRefactoring DesignKataRefactoring Game of Life Kata to PatternsGreat HabitsConsiderations When Writing a New TestConsiderations When Making a Failing Test PassConsiderations After the Test PassesWhen Should I Move to the Next Lesson?ResourcesWebBooks
Section 3
RunningChapter 11Design V – Cohesion and CouplingCouplingTypes of CouplingInteraction CouplingLaw of DemeterMethod Coupling PremisesInheritance CouplingCohesionOther Indicators of Possible Low Cohesion in DesignTypes of CohesionClass CohesionMethod CohesionKatasConnecting Code Smells with Cohesion/CouplingConnecting Object Calisthenics with Code Smells and Cohesion/CouplingWhen to Refactor (Extended for Cohesion/Coupling)Classic TDD FlowThe Big PictureWhen Should I Move to the Next Lesson?ResourcesWebBooks
Chapter 12
Design VI – Solid Principles ++Single Responsibility PrincipleOpen/Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion PrincipleBalanced Abstraction PrinciplePrinciple of Least AstonishmentKataConnecting Cohesion/Coupling and SOLID principlesWhen to Refactor (Extended for SOLID Principles)Classic TDD FlowThe Big PictureWhen Should I Move to the Next Lesson?ResourcesWebBooks
Chapter 13
Design VII – ConnascenceDefinitionDimensionsDegreeLocalityStrengthConnascence of Name and Type (CoN and CoT)Connascence of PositionConnascence of Value (CoV)Connascence of MeaningConnascence of AlgorithmConnascence of Execution OrderConnascence of TimingConnascence of IdentityConnascence of Manual TaskClassic TDD FlowThe Big PictureWhen Should I Move to the Next Lesson?ResourcesWebBooks
Chapter 14
Design VIII –The Four Elements of Simple DesignWhat Are the Four Elements of Simple Design?What Does Each Element Mean?Passes Its TestsMinimizes DuplicationMaximizes ClarityHas Fewer ElementsAlternative Definitions of Simple DesignDefinition #1Definition #2Definition #3Definition #4Definition #5Definition #6Our Personal Definitions of Simple DesignPedroMarcoAlessandroKataElevator Kata by Marco ConsolaroClassic TDD FlowThe Big PictureWhen Should I Move to the Next Lesson?ResourcesWebBooks
Chapter 15
ConclusionCohesion and Coupling as ForcesThe 3 Cs of Design: From Cohesion and Coupling to ConnascenceSystems EntropyThe Relevance of Systems EntropySoftware Development as System BuildingGood Design as a Low-Entropy SystemThe Big PictureResourcesWeb-based resources:Books:
Section 4
FlyingChapter 16Outside-In DevelopmentThe Classic TDD ApproachAcceptance TestsAcceptance Test StylesTest BoundariesDouble Loop TDDThe Outside-In ApproachAn Outside-In MindsetOutside-In TDD: The London SchoolExampleThe Direction of DependenciesShould I Use Classic TDD or Outside-In TDD?KataStock PortfolioKatacombs of Shoreditch by Marco ConsolaroPart IPART IIThe Big PictureGreat HabitsConsiderations When Writing a New TestConsiderations When Making a Failing Test PassConsiderations After the Test Has PassedResourcesWeb-based resources:Books:
Chapter 17
Behavior-Driven DevelopmentPoka-YokeMistakes versus Defects: Feedback Is the Cure (Again)Bugs and CommunicationUser StoriesBehavior-Driven DevelopmentThe Structure of a StoryAcceptance Criteria: It's All about the ExamplesFrom Criteria to Acceptance TestsAcceptance Tests Done RightReadable by Business FolksFeature CompleteFastBoundariesThe Walking SkeletonKataThe Messy Delivery Office RequirementsResourcesWeb-based resourcesBooks
Chapter 18
Understand the BusinessKnowledge versus UnderstandingTheory of ConstraintsDomain-Driven Design: What Domain?Beyond Requirements: Knowledge Crunching5 WhysImpact MappingPopcornFlowUser Story MappingEventStormingBusiness Model CanvasValue Streams and Domain EventsBounded Contexts and CommunicationSynchronous versus AsynchronousCommand-Query SeparationBusiness and DevOpsThe First WayThe Second WayThe Third WaySystems Thinking and Sociotechnical OrganizationsResourcesWeb-based resourcesBooks
Chapter 19
Story of Team CTerraformingTeam BuildingThe Backlog: Crunching Knowledge for BreakfastCracking OnFrom Forming to PerformingOutside-In ATDD with Optional Unit TestsThe Green FlagThe Moral of the Story
Chapter 20
ConclusionThe Human FactorTeam PlayBounded Rationality and Knowledge SharingResourcesWebBooks
Chapter 21
The 12 Agile Principles
Chapter 22
PopcornFlow by Claudio PerroneThe 7-Steps Decision CycleThe PrinciplesWho Can Benefit from PopcornFlowResourcesWeb-based resources:Books:
Chapter 23
EventStorming by Alberto BrandoliniSilos and Value StreamsThe Importance of LearningThe EventStorming ApproachThe Workshop: A Quick OverviewDifferent Flavors of EventStormingComplex Systems and Proven SolutionsResourcesWebBooks
License: CyberDojo
About CyberDojo Foundation ExercisesWeb Resources
Sample Solutions
Sample Solutions: FizzBuzz in ClojureSample Solutions: Fibonacci Sequence in C++Sample Solutions: Roman Numerals in C#Sample Solutions: Tic-Tac-Toe in Swift (Partial Solution)Sample Solutions: Connecting Code Smells with Cohesion/CouplingSample Solutions: Connecting Object Calisthenics with Code Smells and Cohesion/CouplingSample Solutions: Connecting Cohesion/Coupling and SOLID Principles
Feedback
Personalized CoachingIndividualsOrganizationsFeedback Please

Content preview from Agile Technical Practices Distilled

Chapter 12 Design VI – Solid Principles ++

"Everything should be made as simple as possible, but no simpler."

– Generally attributed to Albert Einstein

Single Responsibility Principle

In object-oriented programming, the Single Responsibility Principle (SRP) states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

The term was introduced by Robert C. Martin. Martin described it as being based on the principle of cohesion as described by Tom DeMarco in his book Structured Analysis and Systems Specification. Cohesion is a measure of the strength of association of the elements inside a module. A highly ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Managing Software Requirements the Agile Way

Publisher Resources

ISBN: 9781838980849Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Agile Technical Practices Distilled

by Pedro M. Santos, Marco Consolaro, Alessandro Di Gioia

Chapter 12

Design VI – Solid Principles ++

Single Responsibility Principle

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.