code retreat @bmw car it

Post on 08-May-2015

1.414 Views

Category:

Technology

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

The slides I used during our code retreat at BMW Car IT.

TRANSCRIPT

1.BMW Car IT Code Retreat

Sebastian.Benz@bmw-carit.de

1. code

2. delete

3. repeat

6x

The point of a code retreat is not to make progress on the problem. The point is to

write perfect code!

Corey Haines

In each session...

1. Set a goal

2. Try to reach it

3. Destroy your code

4. Retrospect

Pair Programming

• Talk about your assumptions, short-term goals, general direction

• Switch roles frequently

• Communication: "This method is too long" vs "Could we make this method shorter?"

• Exercise: Ping-Pong-Pairing - one person writes a test, the other tries to fix it.

more http://jamesshore.com/Agile-Book/pair_programming.html

Session IGet to know the problem...

Conway‘s Game of Life

Conway‘s Game of Life

1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.

1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.

1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.

2. Any live cell with two or three live neighbours lives on to the next generation

2. Any live cell with two or three live neighbours lives on to the next generation

3. Any live cell with more than three live neighbours dies, as if by overcrowding.

3. Any live cell with more than three live neighbours dies, as if by overcrowding.

4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

Notes

• All rules are applied simultaneously

• Start by focusing on the rules

• No GUI - use tests instead

Session IIEverything is an object.

Cell

Cell

Cell Cell

neighbours

Example

Cell Cell

Cell

Cell

vs.

Challenge

• Thou shalt not use arrays.

Session IIITest-drive your design.

Test-first ≠ Test-driven

TDD

Write a failingunit test

Make the test pass

Refactor

TDD as if you meant it

• Write one failing test

• Make the test pass by writing implementation code in the test

• Create a new implementation method/function by:

• extract method on implementation code from (2), or

• moving implementation code from (2) into an existing method

• Only ever create new methods in the test class

• Only ever create implementation classes to provide a destination for extracting a method created as per (4).

• Populate implementation classes by moving methods from a test class

• Refactor

Example

Challenge

• Thou shalt TDD as if thou meant it.

• Thou shalt not use the debugger.

• Thou shalt know in advance which test will fail.

Session IVIts all about the looks...

"There are two hard problems in computer science: cache invalidation, naming things, and

off-by-one errors."

Eric Florenzano / Phil Karlton

"There are two hard problems in computer science: cache invalidation, naming things, and

off-by-one errors."

Eric Florenzano / Phil Karlton

Example

Challenge

• Thou shalt use good names.

• Thou shalt express your intend by method names.

• Thou shalt have only methods with LOC < 3.

Session VMore challenges...

Challenge

• Thou shalt use only functions and constants.

or

• Thou shalt not use loops (while, for, iterators,..).

Session VIThe end game...

top related