An introduction to a coding dojo session held in Florence (Italy) on May 19, 2017

1. Coding dojo
Practice makes perfect

2. Agenda
Intro - dojo + tdd + warmup kata
Kata - part I
Break
Kata - part II
Feedback
Pizza - if you can/want
30m
30m
10m
30m
10m

3. Welcome to the coding dojo

4. Leverage each other knowledge

5. Coding Dojo
mindset

6. We usually
train on the job

7. We need a place
and time to
experiment and
fail spectacularly

8. You are here to learn not to build
something, no output required
Slow down. Don't focus on getting
it done, focus on doing it perfectly
It is necessary to push to the
extreme to verify the validity of a
technique, hence the dojo

9. Dojo goals
Iterative-Incremental development
Baby steps
TDD cycle

10. Disclaimer
The examples are dead simple
a bit simplistic on purpose,
otherwise we'd be lost trying to
understand the code

11. ?

12. Let's talk
about TDD

13. TDD benefits
Increase chances to catch errors
before production => Lower defects
Increase our confidence to make
changes => Enable refactoring
Encourage more modular design =>
Easier to change

14. is hardTDD

15. TDD is a
multifaceted
technique

16. TDD
Design Refactoring

17. TDD Cycle
Red
Refactor Green
1. Think about the problem
2. Write a test
3. Run it to see it fail
4. Make the test pass
5. Remove duplication

18. Red
Refactor
Green
Constrain the
problem
Make it run. Speed
trumps design
Make it right.
Evolve your design
the magic happens here!
Different phases, different thinking
here most of the time

19. “TDD doesn't drive good design. TDD gives you
immediate feedback about what is likely to be bad
design. If a test is hard to write, if a test is non-
deterministic, if a test is slow, then something is
wrong with the design.”
Kent Beck

21. Let's talk
about Design

22. What is
Design?

23. How you
factor &
arrange
things

24. Design is the result
of the millions of
decisions you've
taken over time

25. design =
stream of
everyday
coding
decision )
fold (

26. How can we
achieve a
good better
design?

27. making the design
easier to change

28. 1. small composable
modules
2. make dependencies
explicit

29. effective design
doesn't guess the
future but leaves
space to move

31. Let's talk
about
Refactoring

32. change implement.
without changing
behaviour
Definition:

33. It's not Refactoring if
Add/Remove a feature
Alter how an object behave

34. It's an essential skill
to change the shape
of your codebase
Emergent design

35. Refactoring goal is
an economic one
Reduce the marginal
cost of the next feature

36. a codebase
become legacy
one day at a time

38. Enough talking...
Warmup exercise: build a
stack which we can push,
pop and peek

39. Tonight kata
You're the new hire at Evil
corporation which is in the
thriving business of censorship
git.io/vHvaq

40. Rules
Proceed one requirements at a time. Don't
cheat
Regex are forbidden, for your own safety :-)
Slow down. Focus on doing it right
Strictly implement what's asked. Try to don't
anticipate design