Introduction to clean code and software design, definitions and approaches

1. A Sweet Taste of Clean Code &
Software Design
Kfir Bloch, Developer
linkedin/in/blochkfir github.com/kfiron@kfirondevkfirb@wix.com http://kfiron.com

2. Hi.
I am Kfir.
coding, open source
software, cooking
HOBBIES
Lithuania
Ukraine
Vilnius
Kyiv
Dnipro
Wix Engineering Locations
Israel
Tel-Aviv
Be’er Sheva

3. As software engineers,
we try to...

4. As software engineers,
we try to...
Develop / deliver fast
Have a software which is
easier to change

5. Clean Code and Software Design
Can help us do it.

6. Clean Code
in a Nutshell

7. Software code that is formatted in a modularized and systematic manner so that
another coder can easily interpret or modify it.
Wikipedia
Clean Code

8. Clean Code
“You can call it beautiful code when the code also makes it look like the language
was made for the problem.”
Ward Cunningham

9. Clean Code
“Clean code always looks like it was written by someone who cares.”
Michael feathers
“You can call it beautiful code when the code also makes it look like the language
was made for the problem.”
Ward Cunningham

10. Clean Code
“Clean code always looks like it was written by someone who cares.”
Michael feathers
“Clean code is about recognizing that your audience isn't just a computer, it's real-
live humans!”
Cory House
“You can call it beautiful code when the code also makes it look like the language
was made for the problem.”
Ward Cunningham

11. Clean Code should be like your car’s dashboard.
A sneak preview gives you all the information you need.

12. Solving a problem
fast isn’t enough.

13. Solving a problem
fast isn’t enough.
Organizing things
for yourself
isn’t enough.

14. Solving a problem
fast isn’t enough.
Organizing things
for yourself
isn’t enough.
Others need to
make sense of it
too.

15. Indentations, White spaces, Tabs
Naming! reveals intent
Small functions
Length of lines
Number of arguments
When to break lines
Structured packages and folders
DRY – don’t repeat yourself
Declarative and expressive
And more…
Clean Code
Characteristics

16. Indentations, White spaces, Tabs
Naming! reveals intent
Small functions
Length of lines
Number of arguments
When to break lines
Structured packages and folders
DRY – don’t repeat yourself
Declarative and expressive
And more…
Clean Code
Characteristics
It’s all about
paying
attention to
the details.

17. Can you tell what this function does?
def send(userId: String, to : String, cc : String, body: String) ={
if(cc != null && !cc.contains("@") && !cc.contains(".")){
Failure(new InvalidEmailException("invalid email"))
} else {
if(to != null && !to.contains("@") && !to.contains("."))
Failure(new InvalidEmailException("invalid email"))
else{
bi.logEmailSent(userId, System.currentTimeMillis())
Success(mail.sendEmail(userId, to, cc, body)
)
}
}
}

18. def sendEmail(emailMessage: EmailMessage): Try[Id] = Try {
validateEmail(emailMessage.to)
validateEmail(emailMessage.cc)
bi.logEmailSent(emailMessage.userId, System.currentTimeMillis())
mail.sendEmail(emailMessage)
}
def validateEmail(email: String): Unit =
if (email != null &&
!email.contains("@") &&
!email.contains(".")) {
throw new InvalidEmailException(s"the email: [$email] is invalid")
}

19. // OK
"Dog service" should {
"add dog" in {
dogHouse.addDog(defaultDog.copy(age = 25)) must beSuccessfulTry
dogHouse.dogsByAge(20, 30) must contain(defaultDog.copy(age = 25))
}
}
// Excellent
"Dog house" should {
"Add dog with age 25 and returns with dogByAgeInMonths()" in {
val dog = defaultDog.withAgeInMonths(25)
dogHouse.addDog(dog) must beDogAdded
dogHouse.dogsByAgeInMonths(from = 20, to = 30) must haveDog(dog)
}
}

20. As your software grows,
it becomes less readable.
It’s all about
paying
attention to
the details.

21. Design
in a Nutshell

22. Make code easier to change
Find where to change
Know fast what to change
Fast reaction to pain, hiding pains
Do not bypass layers, avoid leaky abstractions
Focus about ‘why’ and not ‘how’
Our goals in
design

23. Software Design
Abstraction
Refinement
Modularity
Data Structure
Software Procedure
Information Hiding
Software Architecture
Control Hierarchy
Structure Partitioning

24. Four rules of simple
design:
1. Tests Pass
2. Expresses intent
3. No duplication (DRY)
4. Small
Kent Beck

25. Domain Driven Design (DDD)
- Domain focus, Domain expert
- Bounded contexts
- Building blocks (Entities, Repositories,
Domain event, services)
Eric Evans

26. Approaches for design lifecycles
Big Design Up-Front
Waterfall
Well defined process
Architects culture
UML

27. Big Design Up-Front
Long process
Documents becomes stale
In any case software is changed
and will be changed
Narrows the world of a developer
Waterfall
Well defined process
Architects culture
UML
Approaches for design lifecycles

28. TDD – Beginner’s mind
Code from the first day and make
changes along the way
Don’t care about architecture or
platforms/cloud envs
Approaches for design lifecycles
Evolutionary Design

29. Persistent might be completely
different
Domain might change
dramatically
We expose API which is wrong
but need to be supported
We don’t think about our
consumers
Moving to be eventual consistent
might break everything
Approaches for design lifecycles
Evolutionary Design
TDD – Beginner’s mind
Code from the first day and make
changes along the way
Don’t care about architecture or
platforms/cloud envs

30. If we pay attention to design principles
we’ll be able to change everything.
But we can do better.

31. Obviously, there is large spectrum
between the 2 approaches.
Evolutionary
Design
Big
Design
Up-Front

32. Evolutionary
Design
Big
Design
Up-Front
There’s no one coherent solution.
We’re engineers!
Like doctors, we need to look for a good fit.

33. Tools for determining where your
project is on the spectrum

34. #1 | Size Matters

35. #1 | Size Matters
Big project:
We need some
up-front design
Smaller
project:
Beginner’s
mind might
work

36. #2 | Lifecycle Matters
Kent Beck

37. #2 | Lifecycle Matters
Beginner’s mind
Should be done with
design, and we gain info
already

38. #3 | Consumers Matter
Are we exposing internal APIs?
Are we exposing external APIs?
Are we producing / consuming
events from queue?
It is always a good
idea to design the
domain and API
with your consumers

39. Walking skeleton is great, but not enough.
You need to actually develop the obvious
on the first day – Sunny day with minimum.
#4 | Fill in the obvious
Filling in the obvious
gets you into the
domain, feel the pain
and address it.
There are more unknown pains that you be
able to discover only when start coding

40. #5 | YAGNI is no excuse to deliver bad design
Sometimes, taking the time to think in advance
about design details is a good thing.
You’re an engineer, you get paid to think.

41. #5 | YAGNI is no excuse to deliver bad design
Sometimes, taking the time to think in advance
about design details is a good thing.
You’re an engineer, you get paid to think.
#6 | TDD is not Test-Driven Design
It’s not enough that your tests pass.
Your software can still suck.
TDD is a tool that gives you confidence in design.

42. Clean Code Design
Takeaways
You wake up in the morning to deliver,
sustainable delivery.

43. Clean Code Design
Takeaways
You wake up in the morning to deliver,
sustainable delivery.
Even though you code for the machine,
it needs to be read as a story for humans.

44. Clean Code Design
Takeaways
You wake up in the morning to deliver,
sustainable delivery.
Even though you code for the machine,
it needs to be read as a story for humans.
Find the balance between
up-front design and evolutionary design.

45. Clean Code Design
Takeaways
You wake up in the morning to deliver,
sustainable delivery.
Even though you code for the machine,
it needs to be read as a story for humans.
Find the balance between
up-front design and evolutionary design.
You get paid to make hard and ???
decisions.

46. Thank You
linkedin/in/blochkfir github.com/kfiron@kfirondevkfirb@wix.com http://kfiron.com