CODE RETREAT

$ PROGRAMMERS HONING THEIR CRAFT TOGETHER

WHAT IT IS?

intensive practice event,

focus on the fundamentals of software development

and design,

focus on skill improvement.

WHY WE DO IT?

learn through pairing,

extend your comfort zone,

practice,

experiment,

learn new practices.

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).

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

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!

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).

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.

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.)

WHAT ARE THE RULES FOR

PING PONG PAIR PROGRAMMING?

driver – the one coding at a given moment

copilot – the other developer

1. the driver writes a test and then hands the

keyboard to the copilot,

2. the new driver makes the test pass,

3. they refactor together, passing the keyboard as

necessary,

4. they reverse roles and start over with a new test.

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)

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.

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 with < 2 live neighbors die

live cells with 2 or 3 live neighbors live

live cells with > 3 live neighbors die

dead cells with exactly 3 live neighbors will be revived

check this online simulation to understand better how it works.

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)!

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?

15 MINUTES BREAK!!!

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)!

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?

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?

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.

RESOURCES

Links and books of interest

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)

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

APPENDIX

Detailed descriptions for the constraints

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).

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

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.

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.

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.

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.

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.

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++).

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. setup source control repository,

2. setup a timer for 2 minutes interval when you start,

3. write exactly one test: A. if the timer rings and the test is red then revert and start over,

B. if the test is green before timer rings then commit.

4. restart timer (no discussions in between timers),

5. refactor A. if the timer rings and the refactoring is not complete then revert and

start over,

B. if the refactoring is complete before the timer rings then commit.

6. restart the timer (no discussions in between timers),

7. go to step 3,

8. when session time is up delete the code.

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.