Your SlideShare is downloading. ×
Code Retreat
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Code Retreat

403

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
403
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CODE RETREAT $ PROGRAMMERS HONING THEIR CRAFT TOGETHER
  • 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?
  • 16. 15 MINUTES BREAK!!!
  • 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.
  • 21. RESOURCES Links and books of interest
  • 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
  • 24. APPENDIX Detailed descriptions for the constraints
  • 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. 

×