Code retreat @BMW Car IT
35
-
Upload
sebastian-benz -
Category
Technology
-
view
1.413 -
download
1
description
The slides I used during our code retreat at BMW Car IT.
Transcript of Code retreat @BMW Car IT
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...
