[email protected] software craftsmanship webinar series business & agile series:...

4/25/2013

1

[email protected] www.netobjectives.com

1 Copyright © 2007 Net Objectives. All Rights Reserved. 25 April 2013

Software Craftsmanship

How Patterns, Refactoring, And Test‐Driven Development Can Drive an Emergent Design

Scott L. BainNet Objectives


Scott Bain

Senior ConsultantInstruction and Consulting in– Agile Development, Design Patterns,

Test‐Driven DevelopmentAuthor– Emergent Design, Essential Skills for the

Agile Developer

[email protected]

www.sustainabletdd.com

4/25/2013

2


Dialectic Reasoning

Thesis – one viewpointAntithesis – an opposing viewpointSynthesis – the integration of both

Thesis Antithesis

Synthesis

http://en.wikipedia.org/wiki/Dialectic

Hegel

Kant


Synthesis One

Thesis: Agile software development requires little or no up‐front analysis. TDD and Refactoring will get you there. Requirements will change anyway, so why bother?

Antithesis: You cannot build value into software until and unless you understand the problem you are solving, and how you propose to solve it

Synthesis: Determine the knowns (don’t play dumb) and be guided by them. But defer decisions when possible, as you’ll know more tomorrow

4/25/2013

3


Synthesis Two

Thesis: Don’t build things until you know you need them. Building in anticipation leads to excessive complexity and unnecessary cost

Anti‐thesis: Inadequate up‐front design leads to brittle and viscous systems that collapse in the face of new requirements

Synthesis: Design to knowns, but adhere to the critical qualities, principles, practices, and disciplines that reduce the risk and waste of changing the system later


Terminology

Qualities:– Essential aspects of code that we emphasize in creating and/or evaluating it. Gives us names for things we find desirable in code

4/25/2013

4


Qualities

Cohesion (each class or method is “single minded”)

Coupling (dependencies)

No‐Redundancy (one rule in one place)

Encapsulation (hiding everything you can)


Terminology

Principles:– General guidance that leads us to good results. Can appear in many different ways, and are not always achievable, but when they are not followed risk is incurred

4/25/2013

5


The Open‐Closed Principle*

Based on the work of Bertrand Meyer, and ultimately a product of pre‐OO thinking by Ivar JacobsenJacobsen: “All systems change during their life cycles. This must be borne in mind when developing systems expected to last longer than the first version”Meyer: “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification”

*http://en.wikipedia.org/wiki/Open_Closed_PrincipleMeyer

Jacobsen


Example: The Strategy Pattern*

Client Context+request(Strategy s)

Strategy+operation()

Strategy_V2+operation()


New Requirement: add a class

Do not change the code in the context


*Design Patterns, Elements of Reusable Object‐Oriented Software, Gamma, Helm, Johnson, Vlissides

4/25/2013

6


Terminology

Practices:– Built‐in, automatic activities that are always followed regardless of circumstance.

– Examples from non‐software domains include: Sterilizing instruments for doctorsRetaining all documents for lawyersMeasure twice before cutting in woodworking

– A practice must be simple, low‐cost, valuable, and easy to promote across the entire team


Practices

Programming by intention

Encapsulate construction

4/25/2013

7


Practice: Programming By Intention

class Transaction{

public Boolean commit(String command){

Boolean result;

String[] tokens = tokenize(command);

if(isALargeTransaction(tokens)){result = processLargeTransaction(tokens);

}else{result = processSmallTransaction(tokens);

}return result;

}}


Following Our Principles: Open‐Closed

class Transaction{

public Boolean commit(String command){

Boolean result;

String[] tokens = tokenize(command);

normalizeTokens(tokens);

if(isALargeTransaction(tokens)){result = processLargeTransaction(tokens);

}else{result = processSmallTransaction(tokens);

}return result;

}}

4/25/2013

8


Practice: Encapsulate the Constructor

A simple practice that promotes the separation of use from constructionIs the topic of another entire presentation – We’ve got a recorded version available

I’ll show it simply here…


Instead of This…

class Service {public String doOperation(int x) {

//Whatever this doesreturn rVal;

}}

class Client {Service myService;Client() {

myService = new Service();}

public void m() {// Other stuffmyService.doOperation(10);//

}}

4/25/2013

9


We Do This…*

class Service {public static Service getInstance() {

return new Service();}public String doOperation(int x) {

//Whatever this doesreturn rVal;

}

class Client {Service myService;Client() {

myService = Service.getInstance();}

public void m() {// Other stuffmyService.doOperation(10);//

}}

*Based on a recommendation by Joshua Bloch in Effective Java


So Later We Can Do This…(The Strategy Pattern)

abstract class Service {public static Service getInstance() {

switch Config.GetServiceVersion();case V1:return new Service_V1();

case V2:return new Service_V2();

}}public abstract String doOperation(int x);

}

class Service_V1 : Service {// impl1

}

class Service_V2 : Service {// impl1

}

//… with little or no change to the client(s)

4/25/2013

10


Terminology

Discipline: – A shared approach to doing work, adopted and adhered to by the team. Requires good training and a commitment of time/effort to adopt, but has a commensurate value associated with it.

– Also creates shared language elements that promote communication and therefore collaboration


Disciplines

Examples:– Pattern‐Oriented Development

Not simply “knowing the patterns”, but a complete design paradigm based on them. Includes analysis, design, implementation, and how patterns work together.

– Test‐Driven Development (including Refactoring)Not simply “up‐front testing”, but using tests to create executable specifications that drive development forward.

4/25/2013

11


Decorator Pattern for Streaming IO

Client

TCPIPStream+ flush()

FileStream+ flush()

U128+ flush()

CompressStream+ flush()

Stream+ output()+ flush()

StreamDecorator0..1

1

Stream myStream = new U128(new CompressStream(

new FileStream(filename)));

*Design Patterns, Elements of Reusable Object‐Oriented Software, Gamma, Helm, Johnson, Vlissides


Decorator's Structure and Behavior

Case: Convert to Unicode, Compress, Flush

Client

U128 Compress FileStreamflush

Convertto U128 compress send

flush flush

Single Behavior, sees only “Stream”

4/25/2013

12


Open‐Closed to a New Decorator

Client


FileStream+ flush()

U128+ flush()



StreamDecorator0..1

ScottsGreatIdea+ flush()

1


Open‐Closed to More Things…

Client

FileStreamSGI Compress

No change to the Client’s code…

4/25/2013

13


Test‐Driven Development

What makes a development process "Test‐Driven"?

– The test cases are used to inform the development process

– The test cases are used to move development forward, and to let us know when we're "done"

– The test cases are a kind of documentation, recording the intentions of the production classes


Test‐Driven vs. Test‐First

Writing tests cases before the production classes is a natural fit, but TDD is more than this. TDD includes:

– Managing Dependencies

– Tests as Specification

– Refactoring

4/25/2013

14


Refactoring*

“Improving the Design of Existing Code”Behavior‐Preserving Change of code – Same outward effect as before– Same tests pass as before– Design/Quality is improved

*Refactoring: Improving the Design of Existing Code by Martin Fowler


Use of Patterns vs. TDD

Patterns are seen as part of the older, up‐front way of doing things

TDD is seen as part of the more modern, agile view

We see them as synergistic: Emergent Design

4/25/2013

15


Synergy: Quality

POD TDD

Patterns promote code quality

Testability is a sign of code quality


Qualities and Patterns:The Strategy Pattern

Client Context+request(Strategy s)

Strategy+operation()



Cohesive

Re‐Usable(No Redundancy)

De‐Coupled

Types Encapsulated

4/25/2013

16


Testability and Qualities

One big virtue of Test‐Driven Development /Design is that it drives the “testability” issue to the forefront in design– A class that is too tightly coupled will be hard to test, because all of its dependencies will have to be tested with it

– A class that is weakly cohesive will be hard to test, because all possible combinations of its multiple responsibilities will have to be tested, due to lack of encapsulation

– Redundancies in the system will produce redundancies in the test(s)


Synergy: Testability/Refactoring

POD TDD

Patterns include “how to test this”

Refactoring routinely leads to patterns

4/25/2013

17


Testing The Decorators

Client


FileStream+ flush()

U128+ flush()



StreamDecorator0..1

MockStream+ flush()

1


The Tests and the Mock

Test

Compress Mock

Test

U128 Mock

4/25/2013

18


Refactoring to Patterns*

Twenty‐seven pattern‐directed refactoringsTwelve design smells Detailed implementation mechanics

*Refactoring to Patterns, Joshua Kerievsky


Synergy: Communication

POD TDD

Patterns help communicate intent

Test form executable specifications

4/25/2013

19


Documentation of Intent

Functional Spec 3.2

Blah blah blahThus and soUnless this or thatBut always finally

How can we determine that this is still up to date, if we return six months later?


How About This? (JUnit)

public class AssetTest {private Random any = new Random();

@Testpublic void testAssetFirstYearStraightLineCalculation() {

double anyValue = any.nextDouble();int anyTerm = any.nextInt();int yearToWriteOff = 1;

double straightLineResult = anyValue / anyTerm;

Asset testAsset = new Asset(anyValue, anyTerm);

assertEquals(straightLineResult, testAsset.getWriteOff(yearToWriteOff), .02);

}}

4/25/2013

20


Synergy: Open‐Closedness

POD TDD

Are all Open‐Closed

Require Open‐Closed


Synergy: The Domain

POD TDD

Good design reflects the problem domain

Testing reveals domain knowledge

4/25/2013

21


Design as Evolution: Emergent Design

Software is valuable relative to the world around us, and the needs it has…The world, and its needs, changeFor software to retain its value, it must changeThe pace of change is increasingSoftware must always be in a state of evolution

Disciplines, Principles, and Practices make it possible…


Practice: Programming By Intention

Application

+request()‐op1()‐op2()‐op3()

public void request(){op1();op2();op3();

}

If we’d neglected to do this (or someone else neglected to do this) the refactor would be extract method.

Testable?

4/25/2013

22


Testability: Refactor ‐ Extract Class

Application

‐myService1+request()‐op1()‐op2()‐op3()

Service1

+getInstance():Service1+op1()

private void op1(){myService1.op1()

}

public Application(){myService1=Service1.getInstance();

}

public static Service1 getInstance(){return new Service1();

}

Service1Test

+testService1()

Application2 Application3


Open‐Closed Principle: Refactor ‐ Extract Interface

Application


Service1


Service1A

+op1()

Service1B

+op1()

public static Service1 getInstance(){if(use1A) {return new Service1A();

} else {return new Service1B();

}}

Service1


Application2 Application3

4/25/2013

23


Patterns: Refactor – Introduce Proxy

Application


Service1

‐myService1Factory+getInstance():Service1+op1()

Service1A

+op1()

Service1B

+op1()

LoggingProxy

+op1()

Service1Factory

+getInstance():ServiceFactory+getService():Service1

public static Service1 getInstance(){return Service1Factory.

getInstance().getService();

}


Patterns: Refactor – Evolve Decorator

Application


Service1

‐myService1Factory+getInstance():Service1+op1()

Service1A

+op1()

Service1B

+op1()

LoggingProxy

+op1()

Service1Factory

+getInstance():ServiceFactory+getService():Service1

Decorator

+op1()

Dec1

+op1()

Dec1

+op1()1

*

4/25/2013

24


Remember Where We Started?

Application

+request()‐op1()‐op2()‐op3()


Complexity When You Need it– But not before you need itGood Design reduces riskRisk is WastefulOver‐Design is Wasteful

Emergent Design:– Qualities can define “good”…– Principles can guide us…– Practices can protect us…– Disciplines can empower us…– …but you can’t stop thinking

Avoiding Over‐Design

http://www.spreadshirt.com/you‐can‐t‐stop‐thinking‐C3376A10586989

4/25/2013

25


Resources for Further Investigation

Design Patterns:– www.netobjectives.com/PatternRepository

Testing, Refactoring, Qualities– www.netobjectives.com/resources


Pattern Repository

4/25/2013

26


Resources

Resources: www.netobjectives.com/resources – Webinars/Training Videos (PowerPoint with audio)– Articles and whitepapers– Pre/post course support Supporting materials– Quizzes– Recommended reading paths– BlogsAnnotated BibliographyAfter‐Course Support (students only)Additional Free On‐line TrainingUser Groups– Business Driven Software Development

http://www.netobjectives.com/bdsdug– Lean‐Agile User Group

http://tech.groups.yahoo.com/group/leanagile – Lean Programming User Group

http://tech.groups.yahoo.com/group/leanprogramming

Join our e‐mail list to receive regular updates and information about our resources and training of interest to you


Net Objectives – Selected Books

Design Patterns Explained, A New Perspective on Object‐Oriented Design. Shalloway, TrottEmergent Design: The Evolutionary Nature of Professional Software Development. BainEssential Skills for the Agile Developer: A Guide to Better Programming and Design. Shalloway, Bain, Pugh, KolskyInterface Oriented Design. PughLean‐Agile Acceptance Test‐Driven Development. Pugh.Lean‐Agile Pocket Guide for Scrum Teams. Shalloway, TrottLean‐Agile Software Development: Achieving Enterprise Agility. Shalloway, Beaver, TrottPrefactoring. Pugh

See www.netobjectives.com/resources/bibliography for a full bibliography

4/25/2013

27


New Webinar Series

Business & AgileThis webinar series, co‐sponsored by Digite, provides a wide view of Agile by starting with presentations on what Agile is and the main methods for adopting it ‐ Scrum and Kanban. It then discusses different ways to start an Agile adoption as well as the dangers of certain common methods of adopting Agile. It then proceeds to investigate different methods on how to scale Agile.

– Agile Implementations: Overviews of Scrum, Kanban, and ScrumbanMay 9, 2013, 9am‐10am PDT

– How to Start an Agile ImplementationJune 5, 2013, 9am‐10am PDT

Series: www.netobjectives.com/business‐and‐agile‐webinar‐series


Conferences

Scrum Gathering 2013 – Each of the Scrum Values guides you down the path of self‐discovery during this

conference wherein the presenters help identify where you might "Up the Ante."– May 6 – 8– Westin Las Vegas Hotel Casino & Spa, Las Vegas NVAgile Development/Better Software West 2013 – Join industry experts and peers for a week jam‐packed with learning sessions that will

help you make a powerful impact in your job role and for your company.– June 2 – 7– Caesars Palace, Las Vegas NVÜberConf 2013 – Java is a technology platform and ecosystem. ÜberConf will educate developers and

explore the powerful languages and tools which are changing the way we create software using the Java Platform.

– July 16 – 19– Westin Westminster, Westminster CO

Series: www.netobjectives.com/events/conferences

4/25/2013

28


Upcoming Public Courses

Seattle, WA– Design Patterns for Agile Developers– July 16‐18

Seattle, WA– Lean‐Agile Project Management Certification by Net Objectives – September TBD

Course Times: 9:00am – 5:00pmMore information: http://www.netobjectives.com/events/public‐courses


Net Objectives Services

Training in Sustainable Product Development

Net Objectives offers the most comprehensive Lean‐Agile training in the world. Our offerings include Lean, Agile Analysis, Design Patterns, Test‐Driven Development, and Lean‐Agile Testing.

Our approach is a blend of principles and practices to provide a complete team and/or enterprise wide training solution.

Certification Programs by Net Objectives

Net Objectives offers certification programs that provides a road‐map of knowledge as well as resources to get there.• Lean‐Agile Project Management Certification• Advanced Lean‐Agile Project Management for

Scrum Masters• Business Product Owner Certification

Net Objectives is not affiliated with the Scrum Alliance

Gap Analysis (“Assessments”)

An effective way to embark on an enterprise level transition to Lean‐Agile methods is to start with an analysis of where you are, where you want to go and options on how to get there that are right for you and your budget.

Lean‐Agile Coaching

While training provides foundational knowledge and is a great jump start, coaching is another effective way to increase the abilities of teams.

Our coaches work with your teams to provide guidance in both the direction your teams need to go and in how to get there.

Coaching provides the knowledge transfer while working on your own problem domain.

4/25/2013

29


Curriculum Roadmap of Our Courses


Questions?

[email protected] software craftsmanship webinar series business & agile series:...

Documents