Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

code design process team management organization tests customer ux & ui culture office architecture infrastructure ux & ui meetings security

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

Jack W. Reeves The C++ Journal Vol. 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

Slide 6

Slide 6 text

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++ Journal Vol. 2, No. 2. 1992 http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf

Slide 7

Slide 7 text

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++ Journal Vol. 2, No. 2. 1992 http://user.it.uu.se/~carle/softcraft/notes/Reeve_SourceCodeIsTheDesign.pdf

Slide 8

Slide 8 text

Programming Source Code SOFTWARE DESIGN ???

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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, Turkey Credit: European Space Imaging

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

No Dependencies Loosely Coupled Some Dependencies Tightly Coupled Many Dependencies

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

The Principles of Clean So!ware Design

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

2

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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.

Slide 37

Slide 37 text

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.

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

/lemiorhan lemiorhanergin.com @lemiorhan LEMi ORHAN ERGiN