As software grows in size and complexity, programmers face increasingly difficult challenges. More bugs make it to production, it takes longer to introduce new features, quality drops and frustration abounds. There may not be a silver bullet, but there are many techniques we can use to make things easier and our job more pleasurable. In this talk, we’ll learn how to be more professional software craftsmen by using a range of techniques for writing clean code. I gave this talk at the June 2015 Sela Developer Conference.

1. © Copyright SELA Software & Education Labs, Ltd. | 14-18 Baruch Hirsch St., Bnei Brak, 51202 Israel | www.selagroup.com
SELA DEVELOPER PRACTICE
May 31st – June 4th, 2015
Noam Kfir
Clean Code

2. is fun and easyor it should be

3. writing code is fun and easy
Programmers are

4. writing code is fun and easy
Programmers are

5. writing code is fun and easy
Programmers are

6. is usually pretty hardbut it shouldn’t be

7. development is hard
Programmers , not puzzles

8. development is hard
Programmers

9. development is hard
Programmers

10. so we
hey, it’s not our fault

11. cutting corners
Programs acquire

12. cutting corners
Programs accrue

13. cutting corners
Programs become

14. cutting corners
Customers become
Managers, testers, support personnel all become
Programmers become

15. to the rescueit’s (probably) better than dirty code

16. but what exactly is clean code?
There is no single universal definition
But when you see it

17. and the experts clearly agree
elegant efficient readable maintainable beautiful simple direct
clear intent shareable expected understandable modifiable testable correct
reusable clear resilient meaningful minimal focused crisp
straightforward accessible real-world good strategic no surprises performant

18. software craftsmanship
“Clean code always looks like
it was ”
Michael Feathers

19. the primal conundrum
: go fast (and make a mess)
vs. or
: go slow (and miss the deadline)

20. the primal conundrum
But it’s the wrong paradigm!
“The only way to make the deadline—the only way to go fast—
is to .”
Robert C. Martin

21. we need some
like a broom, or a towel, or something…

22. training
obviously…
but
internal training, online courses, offline courses, code reviews,
pair programming, code retreats, mentoring, user groups, etc.

23. keep it dry
don’t repeat yourself!

24. SOLID principles
• single responsibility principle
• do just one thing, have one reason to changeSRP
• open closed principle
• open for extension, closed for changeOCP
• liskov substitution principle
• all implementations should behave consistentlyLSP
• interface segregation principle
• implement only necessary abstractionsISP
• dependency inversion principle
• externalize dependencies and rely on abstractionsDIP

25. dependency inversion
all the principles are important,
but is probably dependency inversion
avoid calling constructors
prefer abstractions (interfaces and base classes)
use dependency injection
use inversion of control (IOC) containers

26. meaningful names
meaningful names
expressive code is
do not underestimate their importance, don’t be too lazy

27. meaningful names should:
not be or
not require or
be and and
be
form the backbone for in a team

28. functions
functions should
and they should
keep functions
short means ≈ 5 lines of code

29. refactoring
“Refactoring is the in
such a way that it of the
code yet .”
Martin Fowler
a , part of being professional
refactorings have , like design patterns
avoid “big refactorings” –

30. common refactorings
rename
move
extract variable
extract method
extract parameter
extract interface
inline variable
many more on http://www.refactoring.com/catalog/

31. side effects
side effects are
side effects

32. emergent design
a keeps code clean and facilitates emergent design
by following these :
runs all the tests
contains no duplication
expresses the intent of the programmer
minimizes the number of classes and methods
Kent Beck

33. just the tip of the iceberg
comments are smelly
the law of demeter, a.k.a. only talk to friends
prefer exceptions over error states
use unit tests and test-driven development (TDD)
the boy scout rule
learn to work with third-party and legacy code
design patterns always on your mind
use clean architecture and architectural patterns
and the list goes on…

34. in
you guessed it, we’re almost done

35. summary
clean code is about

36. summary
clean code is about

37. summary
clean code is about

38. summary
clean code is about

39. additional resources
Clean Code: A Handbook of Agile Software Craftsmanship
by Robert C. Martin
http://blog.cleancoder.com/
http://martinfowler.com/
http://www.meetup.com/Clean-Code-Alliance/

40. Questions
Noam Kfir | @NoamKfir | noamkfir@sela.co.il