1. The document summarizes the key points of a code retreat session focused on writing perfect code for Conway's Game of Life simulation through test-driven development. 2. The retreat is divided into sessions that focus on object-oriented design, test-driving code, and ensuring clean code through good naming and short method implementations. 3. The goal is to destroy and rebuild the code multiple times with each iteration focusing on a different aspect of clean, well-tested code.

1. 1.BMW Car IT
Code Retreat
Sebastian.Benz@bmw-carit.de

2. 1. code
2. delete 6x
3. repeat

3. The point of a code retreat is not to make
progress on the problem. The point is to
write perfect code!
Corey Haines

4. In each session...
1. Set a goal
2. Try to reach it
3. Destroy your code
4. Retrospect

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

6. Session I
Get to know the problem...

7. Conway‘s Game of Life

8. Conway‘s Game of Life

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

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

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

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

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

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

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

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

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

18. Notes
• All rules are applied simultaneously
• Start by focusing on the rules
• No GUI - use tests instead

19. Session II
Everything is an object.

20. Example
neighbours Cell
Cell
Cell Cell vs. Cell Cell
Cell
Cell

21. Challenge
• Thou shalt not use arrays.

22. Session III
Test-drive your design.

23. Test-first ≠ Test-driven

24. TDD
Write a failing Make the
unit test test pass
Refactor

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

26. Example

27. Challenge
• Thou shalt TDD as if thou meant it.
• Thou shalt not use the debugger.
• Thou shalt know in advance which test will fail.

28. Session IV
Its all about the looks...

29. "There are two hard problems in computer
science: cache invalidation, naming things, and
off-by-one errors."
Eric Florenzano / Phil Karlton

30. "There are two hard problems in computer
science: cache invalidation, naming things, and
off-by-one errors."
Eric Florenzano / Phil Karlton

31. Example

32. Challenge
• Thou shalt use good names.
• Thou shalt express your intend by method names.
• Thou shalt have only methods with LOC < 3.

33. Session V
More challenges...

34. Challenge
• Thou shalt use only functions and constants.
or
• Thou shalt not use loops (while, for, iterators,..).

35. Session VI
The end game...