These are the slides that I delivered during PHPKonf18 at Istanbul.

1. LEMi ORHAN ERGiN
co-founder @ craftbase
CLEAN
DESIGN
SOFTWARE
THE PRACTICES TO MAKE THE DESIGN SIMPLE

2. codedesign processteam
management
organization
tests customer
ux & ui culture office
architecture infrastructure
ux & uimeetingssecurity

3. things smell…
and if something smells bad, it means it is not clean

4. Let’s talk about what is so!ware design and
how we can build it clean

5. Jack W. Reeves
The C++ JournalVol. 2, No. 2. 1992
http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf
What is So"ware Design?
https://medium.com/t%C3%BCrkiye/yaz%C4%B1l%C4%B1m-tasar%C4%B1m%C4%B1-nedir-cd8aad12c8ae
Türkçe Çevirisi: Muhammed Hilmi Koca

6. Source code is the real
so"ware design
Designing so!ware is an exercise in managing complexity
Jack W. Reeves
What is Software Design? The C++ JournalVol. 2, No. 2. 1992
http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf

7. The so"ware design is
not complete until it has
been coded and tested
Testing is part of the process of refining the design
Jack W. Reeves
What is Software Design? The C++ JournalVol. 2, No. 2. 1992
http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf

8. Programming
Source Code
SOFTWARE DESIGN ???

9. Programming
Source Code
Automated Testing
(Unit, Functional, etc.)
SOFTWARE DESIGN v0.1

11. The very first value of
so"ware is
Robert C. Martin
Author of Clean Code and Clean Coder
Owner of cleancoders.com training site
…

12. to tolerate and
facilitate on-going changes
Robert C. Martin
Author of Clean Code and Clean Coder
Owner of cleancoders.com training site
The very first value of
so"ware is

13. 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 UML
Wrote foreword to
“Design Patterns” and
“Technical Debt” books
Istanbul, TurkeyCredit: European Space Imaging

14. Testing and Refactoring
are first class citizens of
so"ware design
Tests should pass
Refactoring should be continuous

15. Programming
Source Code
Automated Testing
(Unit, Functional, etc.)
SOFTWARE DESIGN v0.1

16. Refactoring
Programming
Source Code
Automated Testing
(Unit, Functional, etc.)
SOFTWARE DESIGN v0.2

17. SOFTWARE DESIGN v0.2
Refactoring
Programming
Source Code
Automated Testing
(Unit, Functional, etc.)
clean?

18. COUPLING
When readFile() is changed, do you change writeFile() too?
It shows how many places we need to change

19. public class CakeCooker {
private Powder cakePowder;
private Event event = new CookingEvent();
public void cook(Cake cake) {
prepareIngredients();
int numberOfLayers = cake.getNumberOfLayers();
cakePowder = new BrownCakePowder();
float weight = cakePowder.getWeightUsed();
Egg egg = new Egg();
egg.crack();
cake.getChef().getCompany().registerEvent(event);
}
private void prepareIngredients() {
// prepare ingredients here ...
}
}
Don't talk to strangers
Law of Demeter
do not reach into an object to gain
access to a third object’s methods
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
example of
high coupling

20. No Dependencies Loosely Coupled
Some Dependencies
Tightly Coupled
Many Dependencies

21. Two elements are loosely
coupled if they are not
shown in the same diff
Kent Beck
The creator of extreme programming
One of the signatories of the Agile Manifesto
Pioneered software design patterns and TDD

22. COHESION
Do you search a lot where to change?
It shows how easy to find the places we need to change

23. public class EmailMessage {
private String sendTo;
private String subject;
private String message;
private String username;
public EmailMessage(String to, String sbj, String m) {
this.sendTo = to;
this.subject = sbj;
this.message = m;
}
public void sendMessage() {
// send message using sendTo, subject, message
}
public void authenticate(String username, String pass) {
this.username = username;
// code to login
}
}
A cohesive module performs
a single task within a
so!ware procedure, requiring
li#le interaction with the
procedures being performed
in other parts of the program
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
example of
low cohesion

24. How many files at any
one time is still open for
edit shows the level of
cohesion
Nat Pryce
Co-Author of Growing Object-Oriented Software Guided by Tests
Early adopter of XP

25. Refactoring
Programming
Source Code
Automated Testing
(Unit, Functional, etc.)
SOFTWARE DESIGN v0.2

26. Refactoring
Low Coupling High Cohesion
SOFTWARE DESIGN v0.3
Programming
Source Code
Automated Testing
(Unit, Functional, etc.)

27. If people program solo, they are
more likely to make mistakes,
more likely to over design, and
more likely drop the other practices,
particularly under pressure.
Kent Beck
The creator of extreme programming
One of the signatories of the Agile Manifesto
Pioneered software design patterns and TDD
— from book “XP Explained” by Kent Beck

28. Higher quality in code
Faster in deployment*
Faster defect removal
Higher morale
Be"er collaboration
Shared knowledge
Quicker to market
Automatic code review
Useful for training people
Lower defect rates
https://www.flickr.com/photos/fraserspeirs/3394902061
Joe O'Brien and Jim Weirich while doing ruby code review
Benefits of Programming in Pairs

29. Refactoring
Low Coupling High Cohesion
SOFTWARE DESIGN v0.3
Programming
Source Code
Automated Testing
(Unit, Functional, etc.)

30. Pair Programming and Code Review
Refactoring
Low Coupling High Cohesion
SOFTWARE DESIGN v0.4
Programming
Source Code
Automated Testing
(Unit, Functional, etc.)

31. The Principlesof Clean So!ware Design

32. 1 tests pass
Tests should always pass.
If you can’t prove that your system works and does what it is required to do
then it doesn’t really ma!er if your design is clean, simple or complex.

33. 2

34. 2 code expresses intent
Reveal what you are doing, not why you are doing or how you are doing
(how)
(what-generic)
(what-specific)
mailer.use_gmail_smtp_send_email()
mailer.send_email()
mailer.send_activation_email()
Give great names.
because you have to live with them forever

35. 2 code expresses intent
manager
handler
helper
utils
facade
repository
wrapper
interceptor
controller
parser
service
validator
converter
gateway
generator
Avoid using honeypot names a!racting behaviors and functionalities
Give great names.
because you have to live with them forever

36. 3 keep it small
Less code is cleaner and
maintainable.
Keep your methods and classes small. I mean really small.
The application shouldn’t have pieces that you don’t need. Delete the unused.

37. 4 do not repeat yourself
Find and remove duplications.
It’s not only about code duplication, it’s also about knowledge duplication.
Every piece of knowledge should have one and only one representation.

38. 5 tame abstractions
Align the level of abstractions.
Do not expose details and limitations of its underlying implementation
to its users that should ideally be hidden away.

39. 5 tame abstractions
All non-trivial abstractions, to
some degree, are leaky.
Abstractions fail. Sometimes a li!le, sometimes a lot. There’s leakage. Things
go wrong. It happens all over the place when you have abstractions.
https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
Law of Leaky Abstractions

40. Singletons
Meaning on Nulls
Sharing state
Static & new keywords
Framework slave coding
Composition over Aggregation
Premature optimization
Primitive obsession
Huge upfront design
Checked exceptions
Stop, or use them wisely

41. tests pass
code expresses intent
keep it small
do not repeat yourself
tame abstractions
1
2
3
4
5

43. /lemiorhan
lemiorhanergin.com
@lemiorhanLEMi ORHAN ERGiN