Software Crafters Barcelona - Prepared Coding Dojo: Tell, Don't Ask kata!
Monday 19 November 2018, 19:00 - 20:00
c/ Aragó 208, 4° 4, Barcelona, España
We'll be doing a different kind of session: we'll be doing a prepared kata. TDD see how a pair would work on the Tell Don't Ask kata by Gabriele Tondi. It is a fantastic case of refactoring based on enforcing the "Tell, Don't Ask" principle (https://martinfowler.com/bliki/TellDontAsk.html) in an existing codebase with an anemic domain model* This kata has been practiced at the Software Crafters meetup (e.g., https://www.meetup.com/es-ES/Software-Crafters-Barcelona/events/255861502/), but you don't need to have attended the previous session to enjoy this one. No prerequisite needed, just show up willing to see a kata developed and energy to learn and share! See you there! About the prepared kata: In a prepared Kata demonstration [... someone is] showing the group their best solution. Not just the finished code, but the entire process from empty editor via Test Driven Development to a full working solution. As they code, they should explain their reasoning and choices, so everyone can follow what is happening and why the code turns out like it does.[...] You will usually choose a pairing partner from the audience to support you. This person has a particular responsibility to point out omissions, typos etc, but actually everyone in the room should try to be supportive and kind. Comments and suggestions for improvements can be experienced as distracting though, so you’re free to ask people to save them for the retrospective.[...]If you’re in the audience watching a Prepared Kata performance, your first priority is to make sure you understand what’s happening. The idea is that you follow in enough detail that you’ll be able to go home and reproduce the whole Kata for yourself afterwards, or in the next dojo meeting. The pair at the front should always be willing to stop and explain their thinking. Your other job is to try to think of better ways to do the Kata. Did the pair produce a good design in the end? Are they taking small steps, especially when refactoring? Would a different order of tests lead to better design insights? From "The Coding Dojo Handbook" by Emily Bache, chapter "Prepared Kata"
Publicado por: Betabeers