Upload
saad-ahmed
View
31
Download
2
Embed Size (px)
Citation preview
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