test driven design - gdg devfest istanbul 2016

Post on 05-Jan-2017

75.951 Views

Category:

Software

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

TEST DRIVENDESIGN

LEMi ORHAN ERGiNsoftware craftsman @ acm

DESIGN LEMi ORHAN ERGiNagile software craftsman @ acm

/lemiorhan lemiorhanergin.com @lemiorhan

managing partner at acm developing since 2001

worked at Sony and eBay/GittiGidiyor consultant, architect, trainer, developer

founder of Software Craftsmanship Turkey ex product owner of Agile Turkey Summit

meetup.scturkey.org summit.agileturkey.org

Jack W. Reeves

The C++ Journal Vol. 2, No. 2. 1992http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf

What is So!ware Design?

Source code is the real so!ware designDesigning so!ware is an exercise in managing complexity

Jack W. ReevesWhat is Software Design? The C++ Journal Vol. 2, No. 2. 1992http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf

The so!ware design is not complete until it has been coded and testedTesting is part of the process of refining the design

Jack W. ReevesWhat is Software Design? The C++ Journal Vol. 2, No. 2. 1992http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf

ProgrammingSource Code

SOFTWARE DESIGN

Test andVerification

The very first value of so!ware is…

Robert C. MartinAuthor of Clean Code and Clean CoderOwner of cleancoders.com training site

The very first value of so!ware is to tolerate and facilitate on-going changes

Robert C. MartinAuthor of Clean Code and Clean CoderOwner of cleancoders.com training site

Each city has to be renewed in order to meet the needs of its populace. So!ware-intensive systems are like that.

Grady Booch

Developed UMLWrote foreword to “Design Patterns” and “Technical Debt” books

Istanbul, TurkeyCredit: European Space Imaging

ProgrammingSource Code

SOFTWARE DESIGN

Refactoring

Test andVerification

Everything is part of the design process

Jack W. ReevesWhat is Software Design? The C++ Journal Vol. 2, No. 2. 1992http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf

but… we develop

without driving

the design

nebulaconcepts and terminology trigger ideas about the design

what we really do in general…

proto-starinitial classes containing the logic

simple structure, basic domain model and behaviors

brown dwarfbasic dependencies, works as we expect

utility classes start to occur

main sequence starneedless complexity starts, a lot of inter-dependencies

manual testing starts to take longer time than usual

hard to add new features too much debugging

too many workarounds too complex to know every flow

red giant

blue-white super giant

single change affects many areas, no reuse - duplication hell,

fragile system - unstable prod scary refactoring,

silos occur

red super gianthuge classes, tons of workarounds, no new features, maintenance mode rules, basic implementations take weeks, no one knows how overall system works, rollbacks a!er deployments, architect saves the company

supernovaemployee turnovers,

frustrated management, blame & fight

black holedeadly loop of total rewrite or exit from the market

ProgrammingSource Code

SOFTWARE DESIGN

Refactoring

Test andVerification

ProgrammingSource Code

SOFTWARE DESIGN

Refactoring

good?

Test andVerification

COUPLINGWhen readfile() is changed, do you change writeFile() too? It shows how many places we need to change

Two elements are loosely coupled if they are not shown in the same diff

Kent BeckThe creator of extreme programmingOne of the signatories of the Agile ManifestoPioneered software design patterns and TDD

COHESIONDo you search a lot where to change? It shows how easy to find the places we need to change

How many files at any one time is still open for edit shows the level of cohesion

Nat PryceCo-Author of Growing Object-Oriented Software Guided by TestsEarly adopter of XP

ProgrammingSource Code

SOFTWARE DESIGN

RefactoringLow Coupling

Test andVerification

High Cohesion

ProgrammingSource Code

SOFTWARE DESIGN

Refactoring

is hard and needs discipline!Test andVerification

Test Driven

High CohesionLow Coupling

ProgrammingSource Code

Test andVerification

SOFTWARE DESIGN

Refactoring

Test Driven

High CohesionLow Coupling

ProgrammingSource Code

Test andVerification

SOFTWARE DESIGN

Refactoring

Test Driven

High CohesionLow Coupling

ProgrammingSource Code

Test andVerification

SOFTWARE DESIGN

Refactoring

Test Driven

High CohesionLow Coupling

ProgrammingSource Code

Test andVerification

SOFTWARE DESIGN

Refactoring

Test Driven

High CohesionLow Coupling

ProgrammingSource Code

Test andVerification

SOFTWARE DESIGN

Refactoring

Test Driven

High CohesionLow Coupling

ProgrammingSource Code

Test andVerification

SOFTWARE DESIGN

Refactoring

Test Driven

High CohesionLow Coupling

ProgrammingSource Code

Test andVerification

SOFTWARE DESIGN

Refactoring

Test Driven

High CohesionLow Coupling

ProgrammingSource Code

Test andVerification

SOFTWARE DESIGN

Refactoring

Test Driven

High CohesionLow Coupling

Unit testing frameworks Mocking frameworks Automated testing types Design principles Refactoring techniques Clean code principles

LEARN

Continuous Integration Source code versioning Notification mechanism Code coverage monitoring

Practice TDD via katas Develop via TDD Acceptance testing via TDD Verify by behaviours via BDD

ESTABLISH

PERFORM

Unit testing frameworks Mocking frameworks Automated testing types Design principles Refactoring techniques Clean code principles

LEARN

Continuous Integration Source code versioning Notification mechanism Code coverage monitoring

Practice TDD via katas Develop via TDD Acceptance testing via TDD Verify by behaviours via BDD

ESTABLISH

PERFORM

Unit testing frameworks Mocking frameworks Automated testing types Design principles Refactoring techniques Clean code principles

LEARN

Continuous Integration Source code versioning Notification mechanism Code coverage monitoring

Practice TDD via katas Develop via TDD Acceptance testing via TDD Verify by behaviours via BDD

ESTABLISH

PERFORM

Unit testing frameworks Mocking frameworks Automated testing types Design principles Refactoring techniques Clean code principles

LEARN

Continuous Integration Source code versioning Notification mechanism Code coverage monitoring

Practice TDD via katas Develop via TDD Acceptance testing via TDD Verify by behaviours via BDD

ESTABLISH

PERFORM

small set of entities few lines in methods

follows OOP design guidelines simple design, names are the intensions

marbles

If you really want to see something interesting:)

ursa minor and polaris

LEMi ORHAN ERGiN

LEMi ORHAN ERGiNagile software craftsman @ acm

/lemiorhan lemiorhanergin.com @lemiorhan

top related