Agile 2012 Simple Design Applied

138
Simple Design Applied Spend more time creating valuable code Declan Whelan @dwhelan Alistair McKinnell @mckinnell

description

Presentation at Agile 2012 Experience and research shows that developers spend as much as 70% of their time reading and understanding code. In this workshop you will learn how the rules of Simple Design help to reduce this percentage so you spend more time creating valuable code. This will be a highly collaborative workshop where you share your insights and learn from others. You’ll get to the heart of Simple Design by reviewing code - both beautiful and ugly. You’ll get to practice by improving the readability and understandability of real code. You’ll leave this workshop ready to apply Simple Design to improve your own code.

Transcript of Agile 2012 Simple Design Applied

Page 1: Agile 2012 Simple Design Applied

Simple Design Applied Spend more time creating

valuable code

Declan Whelan @dwhelan

Alistair McKinnell@mckinnell

Page 2: Agile 2012 Simple Design Applied

Exercise

Page 3: Agile 2012 Simple Design Applied

On an index card write up to three facts on an index card.

Be ready to share with your table.

What is Simple Design?

Page 4: Agile 2012 Simple Design Applied

At your table gather the facts and count how many distinct

facts you came up with.

What is Simple Design?

Page 5: Agile 2012 Simple Design Applied

Introductions

?

Page 6: Agile 2012 Simple Design Applied

www.XProgramming.com

Page 7: Agile 2012 Simple Design Applied
Page 8: Agile 2012 Simple Design Applied

Exercise

Page 9: Agile 2012 Simple Design Applied

At your table order the rules of simple design in

priority order.

Simple Design

Page 10: Agile 2012 Simple Design Applied

1. All tests must pass2. No code is duplicated3. Code is self-explanatory4. No superfluous parts exist

Simple Design

Page 11: Agile 2012 Simple Design Applied
Page 12: Agile 2012 Simple Design Applied

1. All tests must pass2. No code is duplicated3. Code is self-explanatory4. No superfluous parts exist

Simple Design

Page 13: Agile 2012 Simple Design Applied

1. Passes its tests2. No code is duplicated3. Code is self-explanatory4. No superfluous parts exist

Simple Design

Page 14: Agile 2012 Simple Design Applied

1. Passes its tests2. Minimizes duplication3. Code is self-explanatory4. No superfluous parts exist

Simple Design

Page 15: Agile 2012 Simple Design Applied

1. Passes its tests2. Minimizes duplication3. Maximizes clarity4. No superfluous parts exist

Simple Design

Page 16: Agile 2012 Simple Design Applied

1. Passes its tests2. Minimizes duplication3. Maximizes clarity4. Has fewer elements

Simple Design

Page 17: Agile 2012 Simple Design Applied

1. Passes its tests (given TDD)2. Minimizes duplication3. Maximizes clarity4. Has fewer elements

Simple Design

Page 18: Agile 2012 Simple Design Applied

1. Passes its tests (given TDD)2. Minimizes duplication3. Maximizes clarity (fix names)4. Has fewer elements

Simple Design

Page 19: Agile 2012 Simple Design Applied

1. Passes its tests (given TDD)2. Minimizes duplication3. Maximizes clarity (fix names)4. Has fewer elements

Simple Design

Page 20: Agile 2012 Simple Design Applied

That leaves me with two key elementsof simple design: remove duplication and fix bad names. When I remove duplication, I tend to seean appropriate structure emerge, and whenI fix bad names, I tend to see responsibilities slide into appropriate parts of the design.

J. B. Rainsberger

Page 21: Agile 2012 Simple Design Applied

• Remove duplication• Fix bad names

Simple Design

Page 22: Agile 2012 Simple Design Applied

• Fix bad names

Simple Design(for today)

Choosing good names❤• Remove duplication

Commonality & Variability❤

Page 23: Agile 2012 Simple Design Applied

Exercise

Page 24: Agile 2012 Simple Design Applied

Stroop Effect

Green Red BluePurple Blue Purple

Blue Purple RedGreen Purple Green

Green Red BluePurple Blue Purple

Page 25: Agile 2012 Simple Design Applied

blackyellow

Meaning:

Colour:

Page 26: Agile 2012 Simple Design Applied

blueblack

Meaning:

Colour:

Page 27: Agile 2012 Simple Design Applied

blackyellow

Page 28: Agile 2012 Simple Design Applied

yellowred

Page 29: Agile 2012 Simple Design Applied

redyellow

Page 30: Agile 2012 Simple Design Applied

redyellow

Page 31: Agile 2012 Simple Design Applied

blueblue

Page 32: Agile 2012 Simple Design Applied

yellowblue

Page 33: Agile 2012 Simple Design Applied

redred

Page 34: Agile 2012 Simple Design Applied

bluered

Page 35: Agile 2012 Simple Design Applied

yellowyellow

Page 36: Agile 2012 Simple Design Applied

redyellow

Page 37: Agile 2012 Simple Design Applied

redyellow

Page 38: Agile 2012 Simple Design Applied

blueblack

Page 39: Agile 2012 Simple Design Applied

yellowblack

Page 40: Agile 2012 Simple Design Applied

blackblue

Page 41: Agile 2012 Simple Design Applied

redblack

Page 42: Agile 2012 Simple Design Applied

TheEnd

Page 43: Agile 2012 Simple Design Applied

Exercise

Page 44: Agile 2012 Simple Design Applied

CComBstr sVal $.getJSON() int result

Rx rx applyMeasureConstraintToEnableSortingByMeasure() float hp

applyPhq9DateRangeConstraint() public void run() Date genymdhms

m_name Label label IShapeFactory

Customer int i RollOverPerformanceIndicatorsToNextMonthTask

CustomerManager LPSTR lpCmdLine int daysSinceModification

boolean fNewPage UpdatePerfIndValueDecCountCmd DepressionSelfManagementCalculator

PerfIndValueDecCountForMatchingIvpCmd PulseRenderer IndexCardPageLayout sut

Tutorial02

Page 45: Agile 2012 Simple Design Applied

CComBstr sVal $.getJSON() int result

Rx rx applyMeasureConstraintToEnableSortingByMeasure() float hp

applyPhq9DateRangeConstraint() public void run() Date genymdhms

m_name Label label IShapeFactory

Customer int i RollOverPerformanceIndicatorsToNextMonthTask

CustomerManager LPSTR lpCmdLine int daysSinceModification

boolean fNewPage UpdatePerfIndValueDecCountCmd DepressionSelfManagementCalculator

PerfIndValueDecCountForMatchingIvpCmd PulseRenderer IndexCardPageLayout sut

Tutorial02

Page 46: Agile 2012 Simple Design Applied

Find a partner and each of you:

1. select a name you thought was good2. explain why to your partner3. select a name you thought was bad4. explain why to your partner

CComBstr sVal $.getJSON() int result

Rx rx applyMeasureConstraintToEnableSortingByMeasure() float hp

applyPhq9DateRangeConstraint() public void run() Date genymdhms

m_name Label label IShapeFactory

Customer int i RollOverPerformanceIndicatorsToNextMonthTask

CustomerManager LPSTR lpCmdLine int daysSinceModification

boolean fNewPage UpdatePerfIndValueDecCountCmd DepressionSelfManagementCalculator

PerfIndValueDecCountForMatchingIvpCmd PulseRenderer IndexCardPageLayout sut

Page 47: Agile 2012 Simple Design Applied

Choosing Good Names

Page 48: Agile 2012 Simple Design Applied

Choosing Good Names

Use the telephone test for readability. If someone could understand your code when read aloud over the telephone, it's clear enough. If not, then it needs rewriting.

Page 49: Agile 2012 Simple Design Applied

Telephone Test

Goal Donor vs Gold Owner

Date genymdhms

Page 50: Agile 2012 Simple Design Applied

Choosing Good Names

Splitters can be lumped more easily than lumpers can be split.It is easier to combine two concepts that it is to separate them.

Page 51: Agile 2012 Simple Design Applied

Splitting a Lumper

Customer Address

Page 52: Agile 2012 Simple Design Applied

Customer Address

Billing Address Mailing Address Service Address

Splitting a Lumper

Page 53: Agile 2012 Simple Design Applied

Billing Address Mailing Address Service Address

Lumping a Splitter

Page 54: Agile 2012 Simple Design Applied

Customer Address

Billing Address Mailing Address Service Address

Lumping a Splitter

Page 55: Agile 2012 Simple Design Applied

Choosing Good Names

Pronounceable NamesAvoid Encodings

Page 56: Agile 2012 Simple Design Applied

UpdatePerfIndValueDecCountCmd

Pronounceable Names

Page 57: Agile 2012 Simple Design Applied

UpdatePerfIndValueDecCountCmd

DecrementAggregateCommand

Pronounceable Names

Page 58: Agile 2012 Simple Design Applied

Date genymdhms

Pronounceable Names

Page 59: Agile 2012 Simple Design Applied

Date genymdhms

Date generatedTimestamp

Pronounceable Names

Page 60: Agile 2012 Simple Design Applied

LPSTR lpCmdLine

m_name

Avoid Encodings

LPSTR commandLine

name

Page 61: Agile 2012 Simple Design Applied

Choosing Good Names

Intention-Revealing NameRole-Suggesting Name

Page 62: Agile 2012 Simple Design Applied

Intention-Revealing Name

applyMeasureConstraintTo EnableSortingByMeasure()

Page 63: Agile 2012 Simple Design Applied

Intention-Revealing Name

applyMeasureConstraintTo EnableSortingByMeasure()

applyMeasureConstraint()

Page 64: Agile 2012 Simple Design Applied

Role-Suggesting Name

int result

IndexCardPageLayout sut

Page 65: Agile 2012 Simple Design Applied

Choosing Good Names

Ubiquitous Language

Page 66: Agile 2012 Simple Design Applied

CComBstr sVal

Ubiquitous Language

Page 67: Agile 2012 Simple Design Applied

CComBstr sVal

CComBstr calibrationToolName

Ubiquitous Language

Page 68: Agile 2012 Simple Design Applied

Rx rx

Ubiquitous Language

Page 69: Agile 2012 Simple Design Applied

Rx rx

Rx refillable

Ubiquitous Language

Page 70: Agile 2012 Simple Design Applied

applyPhq9DateRangeConstraint()

Ubiquitous Language

The PHQ-9 is the nine item depression scale of the Patient Health Questionnaire.

The PHQ-9 is a powerful tool for assisting primary care clinicians in diagnosing depression as well as selecting and monitoring treatment.

Page 71: Agile 2012 Simple Design Applied

Agile in a FlashSpeed-Learning Agile

Software Development

Jeff Langr andTim Ottinger

edited by Susannah Pfalzer

PragmaticProgrammers

Agile Cards for Agile Teams

Prepared exclusively for Alistair McKinnell Copyright ©2011 Pragmatic Programmers

Page 72: Agile 2012 Simple Design Applied

43 Really Meaningful Names

! Are accurate

! Are purposeful

! Are pronounceable

! Begin well

! Are simple

! Depend on context

! Match name length to scope

Prepared exclusively for Alistair McKinnell Copyright ©2011 Pragmatic Programmers

Page 73: Agile 2012 Simple Design Applied

Alistair McKinnell @amckinnell Declan Whelan @dwhelanNaming Guidelines v1.0 August 2012 ! 1/1

Naming'GuidelinesSystem'of'Names

S1# # Name#pass#the#“telephone”#test.

S2# # There#is#a#clean#name#for#each#concept.#Remember:#later#on#it’s#easier#to#lump#things#together#than#to#split#them#apart.

S3# # Name#is#from#the#problem#or#solu?on#domain#and#support#ubiquitous#language#for#the#team

GeneralG1## Name#is#pronounceable.

G2## Name#avoids#encodings#and#member#prefixes.

G3## Name#suggest#why#it#exists.

G4## Name#suggest#how#it#should#be#used.

G5## Name#suggest#what#it#does.

G6## Name#is#easily#searchable#in#the#code#base.

ClassesC1# If#this#is#an#important#base#class#its#class#name#should#be#a#simple#single#word.

C2# If#this#is#a#subclass#its#class#name#suggests#how#it#differs#from#its#superclass.

C3# The#class#name#is#a#noun#or#a#noun#phrase.

MethodsM1# The#method#name#suggests#why#it#would#be#called.

M2# The#method#is#name#a#verb#or#a#verb#phrase.

Variables/Fields/ArgumentsV1# Its#name#indicate#the#role#it's#playing.

V2# The#length#of#the#name#reflect#its#scope.

Choosing Good Names•Locate one guideline that if applied would have the biggest impact on your code

•Find a partner•Discuss

Page 74: Agile 2012 Simple Design Applied

Choosing Good Namespublic List<int[]> getThem() { List<int[]> list1 = new ArrayList<int[]>();

for (int[] x : theList) if (x[0] == 4) list1.add(x);

return list1;}

Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19

Page 75: Agile 2012 Simple Design Applied

public List<int[]> getFlaggedCells() { List<int[]> flaggedCells = new ArrayList<int[]>();

for (int[] cell : gameBoard) if (cell[STATUS_VALUE] == FLAGGED) flaggedCells.add(cell);

return flaggedCells;}

public List<int[]> getThem() { List<int[]> list1 = new ArrayList<int[]>();

for (int[] x : theList) if (x[0] == 4) list1.add(x);

return list1;}

Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19

Choosing Good Names

Page 76: Agile 2012 Simple Design Applied

public List<Cell> getFlaggedCells() { List<Cell> flaggedCells = new ArrayList<Cell>();

for (Cell cell : gameBoard) if (cell.isFlagged()) flaggedCells.add(cell);

return flaggedCells;}

public List<int[]> getThem() { List<int[]> list1 = new ArrayList<int[]>();

for (int[] x : theList) if (x[0] == 4) list1.add(x);

return list1;}

Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19

Choosing Good Names

Page 77: Agile 2012 Simple Design Applied

public List<Cell> getFlaggedCells() { List<Cell> result = new ArrayList<Cell>();

for (Cell cell : gameBoard) if (cell.isFlagged()) result.add(cell);

return result;}

public List<int[]> getThem() { List<int[]> list1 = new ArrayList<int[]>();

for (int[] x : theList) if (x[0] == 4) list1.add(x);

return list1;}

Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, pages 18-19

Choosing Good Names

Page 78: Agile 2012 Simple Design Applied

Choosing Good Names

int realDaysPerIdealDay = 4;const int WORK_DAYS_PER_WEEK = 5;int sum = 0;

for (int j=0; j < NUMBER_OF_TASKS; j++) { int realTaskDays = taskEstimate[j] * realDaysPerIdealDay; int realTaskWeeks = (realdays / WORK_DAYS_PER_WEEK); sum += realTaskWeeks;}

int s = 0;

for (int j=0; j<34; j++) { s += (t[j]*4)/5;}

const int EFFECTIVE_DAYS_PER_WEEK = 4;const int WORKING_DAYS_PER_WEEK = 5;

int effectiveTotalEstimate = 0;

for (int j=0; j < NUMBER_OF_TASKS; j++) { int effectiveTaskEstimate = taskEstimate[j] * EFFECTIVE_DAYS_PER_WEEK / WORKING_DAYS_PER_WEEK; effectiveTotalEstimate += effectiveTaskEstimate;}

Source: Clean Code: A Handbook of Agile Software Craftsmanship, Robert C. Martin, page 23

Page 79: Agile 2012 Simple Design Applied

What’s In A Name?

Moonbeam Zappa

Page 80: Agile 2012 Simple Design Applied
Page 81: Agile 2012 Simple Design Applied

All tests must pass No code is duplicated

Code is self-explanatory No superfluous parts exist

Page 82: Agile 2012 Simple Design Applied

No code is duplicated

Page 83: Agile 2012 Simple Design Applied

Exercise

Page 84: Agile 2012 Simple Design Applied

How do you handle duplicate code

in your codebase?

Page 85: Agile 2012 Simple Design Applied
Page 86: Agile 2012 Simple Design Applied

DRY: Don’t Repeat YourselfEvery piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Avoiding Duplicate Code

Page 87: Agile 2012 Simple Design Applied

Avoiding Duplicate Code

Once and Only OnceData, structure, or logic should exist in only one place in the system.

Page 88: Agile 2012 Simple Design Applied

Avoiding Duplicate Code

Test-Driven Development1. Write new code only if an

automated test has failed.2. Eliminate duplication.

Page 89: Agile 2012 Simple Design Applied

Single Choice PrincipleWhenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.

Avoiding Duplicate Code

Page 90: Agile 2012 Simple Design Applied

Duplication may be the root of all evil in software.

Avoiding Duplicate Code

Page 91: Agile 2012 Simple Design Applied
Page 92: Agile 2012 Simple Design Applied

Commonality and Variability

Page 93: Agile 2012 Simple Design Applied

Copy & Paste

Page 94: Agile 2012 Simple Design Applied

function something() {

}

Page 95: Agile 2012 Simple Design Applied

function something() {

}

function something() {

}

Page 96: Agile 2012 Simple Design Applied

function somethingElse() {

}

function something() {

}

Page 97: Agile 2012 Simple Design Applied

function somethingElse() {

}

function something() {

}

Page 98: Agile 2012 Simple Design Applied

Duplicate Code

Copy & Paste

☞ Duplicate CodeEdit the Copy

Page 99: Agile 2012 Simple Design Applied

Duplicate Code

Avoid duplication by expressing commonality and variability

explicitly.

Page 100: Agile 2012 Simple Design Applied

function somethingElse() {

}

function something() {

}

Page 101: Agile 2012 Simple Design Applied

Duplicate Code: Select Options

Page 102: Agile 2012 Simple Design Applied

Can you spot the duplicate code?

How would you make the commonality and variation explicit?

Can you spot the commonality and variation?

Page 103: Agile 2012 Simple Design Applied
Page 104: Agile 2012 Simple Design Applied

public static List<SelectOption> createEndMonthList(Date expiryDate) { int selectedMonth = getDateMonth(expiryDate);

SelectOptionsSource months = new SelectOptionsSource(1, 12, selectedMonth); SelectOptions monthOptions = new SelectOptions(months);

return monthOptions.create();}

public static List<SelectOption> createEndDaysList() { int selectedDay = getDateDay(getCurrentDatePlus14Days());

SelectOptionsSource days = new SelectOptionsSource(1, 31, selectedDay); SelectOptions dayOptions = new SelectOptions(days);

return dayOptions.create();}

public static List<SelectOption> createEndYearList() { int selectedYear = getDateYear(getCurrentDatePlus14Days());

SelectOptionsSource years = new SelectOptionsSource(1985, 1985 + 30, selectedYear); SelectOptions yearOptions = new SelectOptions(years);

return yearOptions.create();}

Page 105: Agile 2012 Simple Design Applied

public static List<SelectOption> createEndMonthList(Date expiryDate) { int selectedMonth = getDateMonth(expiryDate);

SelectOptionsSource months = new SelectOptionsSource(1, 12, selectedMonth); SelectOptions monthOptions = new SelectOptions(months);

return monthOptions.create();}

public static List<SelectOption> createEndDaysList() { int selectedDay = getDateDay(getCurrentDatePlus14Days());

SelectOptionsSource days = new SelectOptionsSource(1, 31, selectedDay); SelectOptions dayOptions = new SelectOptions(days);

return dayOptions.create();}

public static List<SelectOption> createEndYearList() { int selectedYear = getDateYear(getCurrentDatePlus14Days());

SelectOptionsSource years = new SelectOptionsSource(1985, 1985 + 30, selectedYear); SelectOptions yearOptions = new SelectOptions(years);

return yearOptions.create();}

Page 106: Agile 2012 Simple Design Applied

public static List<SelectOption> createEndMonthList(Date expiryDate) { int selectedMonth = getDateMonth(expiryDate);

SelectOptionsSource months = new SelectOptionsSource(1, 12, selectedMonth); SelectOptions monthOptions = new SelectOptions(months);

return monthOptions.create();}

public static List<SelectOption> createEndDaysList() { int selectedDay = getDateDay(getCurrentDatePlus14Days());

SelectOptionsSource days = new SelectOptionsSource(1, 31, selectedDay); SelectOptions dayOptions = new SelectOptions(days);

return dayOptions.create();}

public static List<SelectOption> createEndYearList() { int selectedYear = getDateYear(getCurrentDatePlus14Days());

SelectOptionsSource years = new SelectOptionsSource(1985, 1985 + 30, selectedYear); SelectOptions yearOptions = new SelectOptions(years);

return yearOptions.create();}

Page 107: Agile 2012 Simple Design Applied

Select Options

create()

SelectOptions

create()

SelectOptions

getFirst()getLast()isSelected()

SelectOptionsSource

Commonality Variability Resolution

Behaviour Collaborator Encapsulate Collection

Page 108: Agile 2012 Simple Design Applied

Select Options

Commonality Variability Resolution

Data Structure Value of State Simple Java Type

getFirst()getLast()isSelected()

SelectOptionsSource

create()

SelectOptions

Page 109: Agile 2012 Simple Design Applied
Page 110: Agile 2012 Simple Design Applied

Select Options

create()

SelectOptions

Encapsulate Collection

create()

SelectOptions

getFirst()getLast()isSelected()

SelectOptionsSource

Page 111: Agile 2012 Simple Design Applied

Select Options

getFirst()getLast()isSelected()

SelectOptionsSource

create()

SelectOptions

ParameterObject

Page 112: Agile 2012 Simple Design Applied

Duplicate Code: Compound Result Handler

Page 113: Agile 2012 Simple Design Applied

Can you spot the duplicate code?

How would you make the commonality and variation explicit?

Can you spot the commonality and variation?

Page 114: Agile 2012 Simple Design Applied

if ( ... ) {

} else {

}

Page 115: Agile 2012 Simple Design Applied

Compound Result HandlerisNegative()isPositive()

CompoundResultClassifier

toNumber()

AbstractCompoundResultClassifier

isNegative()isPositive()

QueensCompoundResultClassifier

isNegative()isPositive()

StandardCompoundResultClassifier

CompoundResultHandler

Page 116: Agile 2012 Simple Design Applied

Compound Result HandlerisNegative()isPositive()

CompoundResultClassifier

toNumber()

AbstractCompoundResultClassifier

isNegative()isPositive()

QueensCompoundResultClassifier

isNegative()isPositive()

StandardCompoundResultClassifier

CompoundResultHandler

Page 117: Agile 2012 Simple Design Applied

Compound Result Handler

Commonality Variability Resolution

Behaviour Implementation Inheritance(Object-Oriented)

isNegative()isPositive()

CompoundResultClassifier

toNumber()

AbstractCompoundResultClassifier

isNegative()isPositive()

QueensCompoundResultClassifier

isNegative()isPositive()

StandardCompoundResultClassifier

CompoundResultHandler

Page 118: Agile 2012 Simple Design Applied

isNegative()isPositive()

CompoundResultClassifier

toNumber()

AbstractCompoundResultClassifier

isNegative()isPositive()

QueensCompoundResultClassifier

isNegative()isPositive()

StandardCompoundResultClassifier

CompoundResultHandler

Commonality Variability Resolution

Behaviour Implementation Inheritance(Object-Oriented)

Compound Result Handler

Page 119: Agile 2012 Simple Design Applied

Compound Result HandlerisNegative()isPositive()

CompoundResultClassifier

toNumber()

AbstractCompoundResultClassifier

isNegative()isPositive()

QueensCompoundResultClassifier

isNegative()isPositive()

StandardCompoundResultClassifier

CompoundResultHandler

Commonality Variability Resolution

Implementation None Base Class

Page 120: Agile 2012 Simple Design Applied

Compound Result HandlerisNegative()isPositive()

CompoundResultClassifier

toNumber()

AbstractCompoundResultClassifier

isNegative()isPositive()

QueensCompoundResultClassifier

isNegative()isPositive()

StandardCompoundResultClassifier

CompoundResultHandler

Commonality Variability Resolution

Implementation None Base Class

Page 121: Agile 2012 Simple Design Applied

Factory

Compound Result Handlerpublic static CompoundResultClassifier createCompoundResultClassifier( Patient sourcePatient) { return isRegisteredAtQueens(sourcePatient) ? QUEENS : STANDARD;}

private static boolean isRegisteredAtQueens(Patient sourcePatient) { return sourcePatient.getDataWarehouse().equals(DataWarehouseTag.QHN);}

Page 122: Agile 2012 Simple Design Applied
Page 123: Agile 2012 Simple Design Applied

Avoiding Duplicate Code

Page 124: Agile 2012 Simple Design Applied

Commonality and Variability

Page 125: Agile 2012 Simple Design Applied

Duplicate Code

Copy & Paste

☞ Duplicate CodeEdit the Copy

Page 126: Agile 2012 Simple Design Applied

Duplicate Code

Avoid duplication by expressing commonality and variability

explicitly.

Page 127: Agile 2012 Simple Design Applied
Page 128: Agile 2012 Simple Design Applied

All tests must pass No code is duplicated

Code is self-explanatory No superfluous parts exist

Page 129: Agile 2012 Simple Design Applied

0 10 20 30 40 50 60 70 80

0 10 20 30 40 50 60 70 80

Page 130: Agile 2012 Simple Design Applied

0 10 20 30 40 50 60 70 80

0 10 20 30 40 50 60 70 80

Page 131: Agile 2012 Simple Design Applied

“The prime directive that was unanimously agree upon by allpresent was that in the nexttens years Agile leaders must

Demand Technical Excellence.”

Jeff Sutherland

Page 132: Agile 2012 Simple Design Applied

“Failure to do that meansyou are not an Agile leader.”

Jeff Sutherland

Page 133: Agile 2012 Simple Design Applied

Personal Action Plan

Page 134: Agile 2012 Simple Design Applied

ReadingThe Elements of Programming StyleKernighan and Plauger

PrefactoringExtreme Abstraction Extreme Separation Extreme ReadabilityKen Pugh

Agile in a FlashSpeed-Learning Agile

Software Development

Jeff Langr andTim Ottinger

edited by Susannah Pfalzer

PragmaticProgrammers

Agile Cards for Agile Teams

Prepared exclusively for Alistair McKinnell

Agile in a FlashSpeed-Learning Agile DevelopmentJeff Langr and Tim Ottinger

Page 135: Agile 2012 Simple Design Applied

ReadingClean CodeA Handbook of Agile Software CraftsmanshipRobert C. Martin

Domain Driven DesignTackling Complexity in the Heart of SoftwareEric Evans

Implementation PatternsKent Beck

Page 137: Agile 2012 Simple Design Applied

ReadingDesign Patterns: Elements of Reusable Object-Oriented Software Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Multi-Paradigm Design for C++James O. Coplien

Lean Architecture: for Agile Software DevelopmentJames O. Coplien and Gertrud Bjørnvig