2. WHAT IT IS?
intensive practice event,
focus on the fundamentals of software development
and design,
focus on skill improvement.
3. WHY WE DO IT?
learn through pairing,
extend your comfort zone,
practice,
experiment,
learn new practices.
4. HOW WE DO IT?
Normally:
organized Saturdays,
it takes a full day (6 sessions).
This code retreat:
organized Wednesday (October 23rd, 2013),
it takes only 3 hours because of work constraints (2
sessions).
5. HOW WE DO IT?
introduction - 30 min
first session – 45 min
retrospective for first session – 15 min
break – 15 min
second session – 45 min
retrospective for second session – 15 min
final retrospective & closing
6. HOW WE DO IT?
only pair programming,
switch pairs when session ends,
use any language
(preferably C# or Java for this retreat),
delete the code when session ends,
do not try to finish the problem,
focus on practice,
enjoy!
7. WHY USE CONSTRAINTS?
learn new things,
expand our comfort zone,
improve the way we design software,
learn communication through tests
(tests as a form of documentation).
8. WHAT CONSTRAINTS?
the four elements of simple design,
no conditionals (if, while, etc),
no primitives (int, boolean etc, just objects),
four lines of code per methods,
law of Demeter (use only one dot per line),
no mouse/touchpad (keyboard only),
no IDE (text editor only),
taking baby steps,
object calisthenics,
immutable objects only.
9. WHAT? PAIR PROGRAMMING GAMES?
ping pong (one person writes the tests, the other
person writes the implementation code to make the
test pass),
mute pairing (no one talks, this improves the
readability of the code),
mute with find the loophole (AKA evil coder; the
implementation person purposely writes the wrong
algorithm that still makes the tests turn green. The
key is that they have to keep the code very clean all
the while. So, no big long if statements parsing on
the input parameters.)
10. WHAT ARE THE RULES FOR
PING PONG PAIR PROGRAMMING?
driver – the one coding at a given moment
copilot – the other developer
1.
2.
3.
4.
the driver writes a test and then hands the
keyboard to the copilot,
the new driver makes the test pass,
they refactor together, passing the keyboard as
necessary,
they reverse roles and start over with a new test.
11. WHAT ENVIRONMENT?
C#
Visual Studio IDE (preferably with ReSharper)
NUnit testing framework
Java
Eclipse or IntelliJ IDEA IDEs
JUnit testing framework
git bash (or any other git client)
12. WHAT DO WE CODE?
traditionally the Conway's Game of Life,
can also be Tic-Tac-Toe, but this has a small
disadvantage: you might be able to finish it in a
session which is not so good.
13. WHAT ARE THE RULES?
having an infinite 2D orthogonal universe
being given an initial generation called seed
the following rules are applied simultaneously
live cells
live cells
live cells
dead cells
revived
with
with
with
with
< 2 live neighbors die
2 or 3 live neighbors live
> 3 live neighbors die
exactly 3 live neighbors will be
check this online simulation to understand better how it works.
14. FIRST SESSION
you have 5 minutes to get prepared,
pick your pair,
use ping pong pair programming,
don’t use constraints,
just get a feel for the problem domain,
start coding (and the countdown timer)!
15. FIRST SESSION’S RETROSPECTIVE
do you find it easy to delete the code?
why do you think we should do that?
what would happen if you didn’t delete it?
17. SECOND SESSION
you have 5 minutes to get prepared,
pick your pair (different than in the first session),
use ping pong pair programming,
pick a constraint,
start coding (and the countdown timer)!
18. SECOND SESSION’S RETROSPECTIVE
is an array the right way to store the cells?
(talk about the “primitive obsession” code smell),
what constraints did you choose and why?
19. FINAL RETROSPECTIVE & CLOSING
what, if anything, did you learn today?
what, if anything, surprised you today?
what, if anything, will you do differently in the
future?
what can be improved regarding the organization of
the code retreat?
20. WANT MORE?
Global Day of Code Retreat (#gdcr twitter hash
tag),
This year on December 14th,
Legacy Code Retreat – practice writing tests,
refactoring, improving the design in existing code
(since many of us don’t have the privilege of
working on a greenfield project),
Coding Katas – programming exercises which help
the programmer to improve his/her skills through
practice and repetition.
22. LINKS
video introduction to code retreats
how others do it: The Orlando Code Retreat Video
main site: coderetreat.org
awesome site by Uncle Bob: cleancoders.com
coding kata catalogue
the software craftsmanship movement
software craftsmanship community (contributor
there)
23. BOOKS
Clean Code
by Robert C. Martin
The Coding Dojo Handbook
by Emily Bache
Refactoring
by Martin Fowler
Working Effectively
with Legacy Code
by Michael Feathers
25. THE FOUR ELEMENTS OF SIMPLE DESIGN
The code:
passes it’s tests (tests always on green),
minimizes duplication (extract methods),
maximizes clarity (better names, SRP, etc),
has fewer elements (less code is better most of the
time).
26. NO CONDITIONAL STATEMENTS
no if/while/switch etc statements
the conditional operator (?:) is permitted
boolean expressions are also permitted
you can also use maps instead of switches
27. NO PRIMITIVES
with this we’re trying to fix the “primitive
obsession” code smell,
it basically means that you shouldn’t use primitive
data types (int, double, boolean, string) to
represent domain ideas,
we introduce a Value Object in place of the
primitives, and other code spread around will be
moved in the Value Object,
this is a way to minimize duplication.
28. FOUR LINES OF CODE PER METHOD
programmers have a way of being “comfortable”
with the code: instead of creating a new method for
something (too hard), they add code to an existing
method making it bigger and harder to test (that is if
they have tests at all),
this constraint will force you to use SRP (the Single
Responsibility Principle),
an easy way to do this is “extract till you drop”
(see Uncle’s Bob Clean Code book) which tells that
you should extract new methods from an existing
one till you don’t have anything else to extract.
29. LAW OF DEMETER – IN PLAIN ENGLISH
also called the principle of least knowledge,
your method can call other methods in its class
directly,
your method can call methods on its own fields
directly (but not on the fields' fields),
when your method takes parameters, your method
can call methods on those parameters directly,
when your method creates local objects, that
method can call methods on the local objects.
30. LAW OF DEMETER – FUNNY DEFINITION
you can play with yourself,
you can play with your own toys (but you can't take
them apart),
you can play with toys that were given to you,
you can play with toys you've made yourself.
Real Life™ analogy: when one wants a dog to
walk, one does not command the dog's legs to walk
directly; instead one commands the dog which then
commands its own legs.
31. NO MOUSE/TOUCHPAD (KEYBOARD ONLY)
programmers who know keyboard shortcuts (to
build, to run tests, to execute) work faster and are
usually less distracted,
you should learn the keyboard shortcut equivalents
for most of the operations you usually do on the
normal work day,
you should know the Windows ones too:
Win + E open new explorer window,
Alt + D go to address bar,
etc.
32. NO IDE (TEXT EDITOR ONLY)
this is addressed to those that work the entire day
in an IDE (Visual Studio, Eclipse, IntelliJ IDEA,
others),
do you know what the IDE does (what commands,
what parameters) for you when you
compile/build/deploy the code?
can you manage to put the imports/usings by hand?
can you work without syntax highlighting? Using
just Notepad (no Notepad++).
33. TAKING BABY STEPS
a small step is sure and steady, whereas when taking a large step you
could be in danger of breaking the tests.
Steps - credits to Adrian Bolboaca
1.
2.
3.
setup source control repository,
setup a timer for 2 minutes interval when you start,
write exactly one test:
A.
B.
4.
5.
restart timer (no discussions in between timers),
refactor
A.
B.
6.
7.
8.
if the timer rings and the test is red then revert and start over,
if the test is green before timer rings then commit.
if the timer rings and the refactoring is not complete then revert and
start over,
if the refactoring is complete before the timer rings then commit.
restart the timer (no discussions in between timers),
go to step 3,
when session time is up delete the code.
34. IMMUTABLE OBJECTS ONLY
no setters for object fields,
easier to debug code when there’s nothing that can
mutate,
extremely helpful when dealing with concurrency,
applicable to value types.
