Download as PDF, PPTX
![Coin Changer Kata
Simulate providing change for 1 to 99 cents:
• Develop tests and a method that given an integer (or int)
returns the minimal number of coins to make that change.
• Use this version of Coin Change kata (it’s simpler), instead
of the one that asks for all possible combinations.
• Coins are quarters, dimes, nickels and pennies. Ignore half
dollars.
• Before starting, choose a way to represent the coins. Either
as an array of strings [“quarter”, “dime”, “dime”, “penny”] or
as single string “QDDP”, e.g.:
1 -> [“penny”] or “P”
2 -> [“penny”, “penny”] or “PP”
67 -> [“quarter”, “quarter”, “dime”, “nickel”, ”penny”, ”penny”] or “QQDNPP”](https://image.slidesharecdn.com/katayourwaytoswcraftsmanship20190805-190806010132/75/Kata-Your-Way-to-SW-Craftsmanship-33-2048.jpg)
Uploaded byCamille Bell
Kata Your Way to SW Craftsmanship
The document outlines the concept of code katas, emphasizing their role in enhancing software craftsmanship through practice, specifically in test-driven development (TDD) and pair programming. It details the structure and benefits of conducting code katas in dojos, provides guidance on selecting katas, and introduces several examples such as FizzBuzz and Coin Changer. Additionally, it highlights the importance of good facilitation and offers resources for further learning on TDD and refactoring.
More Related Content
Similar to Kata Your Way to SW Craftsmanship
Kata Your Way to SW Craftsmanship
- 1. TDD Kata Your Way toSoftware Craftsmanship
- 2. About Me • AgileTechnical and Process Coach, Course Designer, Trainer and Developer • Over 4 decades of IT. All sorts of companies, languages, domains, technologies & IT roles. • Email: cbell@CamilleBellConsulting.com • Twitter: @agilecamille (I don’t tweet much) • Slideshare: camille_bell
- 3. Software Craftsmanship • Traditionallycraftsmen practiced a lot and worked under masters, who guided them in their craft • Doctors still work as apprentices under masters in their internships and residencies, while musicians practice scales and other exercises, all to improve their mastery • But software developers don't have a tradition of practice to master our craft • At Code Dojos, we use Katas to practice TDD, Refactoring and Pairing filling this gap
- 4. What a CodeKata Is • Term comes from Martial Arts • A Kata is a small practice exercise • Katas provide an opportunity to practice software craftsmanship • NOT production code, so developers can try new things and learn without pressure • Best when practiced at Dojos in pairs or mobs (working together enhances learning)
- 5. Katas /w DojosPromote Software Craftsmanship • Test Driven Development • Refactoring • Mob & Pair Programming • Collective Code Ownership • Version Control (used in later Katas) • Different Programming Techniques & Designs Provides Practice in:
- 6. Test Driven Development Developin Baby Steps • Write a tiny test • Watch it fail • Write only enough code to make it pass - KISS • Watch it pass • If the code gets messy, refactor in baby steps • Repeat
- 7. Simplified TDD Flow (oftencalled Red-Green-Refactor Write a failing unit test for new functionality Write just enough code to pass test Refactored code must also pass tests, no new functionality TDD is Deep Inside Code: Testing at Unit Level
- 8. • Tests Pass •Clear • DRY • Small 4 Rules of Simple Design
- 9. • Passes alltests all time – Write your unit tests first – Your code passes all these tests – Not done until you can’t think of any more unit tests to write • Clear, Reveals intention (Self documenting code) – Code should be clear, expressive and consistent – Meaningful names of variables, methods, classes etc. – Format for readability, use braces and white spaces, break up long lines, etc. – Change comments into methods, assertions – Etc. 4 Rules of Simple Design (in detail)
- 10. • Don’t RepeatYourself (DRY) – No duplication in code, behavior or configuration – Once and only once • Small – Lines of code per method should be few – Parameters per method should be few – Number of methods in a class should be few – Number of classes in a module or package should be few 4 Rules of Simple Design (detail continued)
- 11. Pair Programming isn’tjust programming It’s more including: • Making design decisions • Implementing code (test & production) • Reviewing code (test and production) • Testing code • Refactoring coding (test and production) • Communicating with your partner and indirectly the whole team • Educating each other and indirectly the whole team • Etc.
- 12. Choose a Facilitatorfor the Code Kata Dojo A good facilitator should: • be proficient with Test Driven Development & Refactoring • be experienced Pair Programmer or Mobber • understand 4 Rules of Simple Design • be good with people, respected by peers A good facilitator is important in the beginning
- 13. Facilitating Dojos withCode Katas Choose a Programming Style: • Mobbing / Randori Style – Best in the beginning • Pair Programming – Good for seasoned Test Driven Developers – Stress Ping Pong Pairing
- 14. Choosing Code Katas •Start with the simples katas 1. FizzBuzz 2. Coin Changer 3. Roman Numerals (Arabic to Roman first) 4. Etc. • After developers consistent with TDD – Explore Refactoring Katas (good practice before refactoring your own legacy code) – Complex Business Rules – Mocking, etc.
- 15. Equipment for CodeKatas Dojos • Large screen and PC projector or very large monitor in front of room • Table in front of room for laptop with two comfortable chairs • Space where everyone not at front table can sit next to each other and view monitor • Laptop(s) configured with programming language, unit test tool and IDE
- 16. Equipment (continued) • Formobbing, only one table • For mobbing, chairs don’t need tables, but do need easy rotation to front table • For pairing, tables and chairs set up classroom style with two sharing a laptop • Posters or handouts of 4 Rules of Simple Design, Test Driven Development, etc.
- 17. Randori / Mobbing Shared Compute r Someone Writesfirst failing test Then new developer 1. Makes test pass 2. Refactors (as needed) 3. Ensures all tests still pass 4. Writes new failing test Next developer, etc. Raj Mary Tom Carlos Eva Selena One developer hands on keyboard Everyone else may make suggestions when asked
- 18. Room Layout forMobbing/Randori Huge High Res Monitor Table with laptop Chairs Possible to use a conference room table for rotation, But moving around a conference room table takes extra time
- 19. Ping Pong Pairing(at pairing station) Shared Compute r Mary Tom Write a failing test Make test pass Refactor & run tests Write a failing test Make test pass Refactor & run tests Write a failing test Make test pass etc. Make test pass Refactor & pass tests Write a failing test Make test pass Refactor & pass tests Write a failing test Make test pass Refactor & pass tests Write a failing test etc.
- 20. Room Layout forPair Programming Huge High Res Monitor Pairing Stations Front Table to Share Results
- 21. Before Facilitating Your FirstCode Kata • Choose the Kata • Practice the Kata yourself • Watch videos of the chosen Kata after practicing the Kata
- 22. Running the CodeKata Dojo • Present the Red, Green, Refactor TDD Cycle • Present the 4 Rules of Simple Design • Facilitate if Mobbing • Walk the room & help, as needed, if Pair Programming • At the end, if Pairing, pairs volunteer to share tests & code on large monitor
- 23. • Don’t havea PC or laptop with the needed compiler, unit test tool or IDE for the desired programming language • But do have web access • Try http://cyber-dojo.org/
- 24.
- 25. Pair Programming • Allproduction code written with 2 programmers at 1 machine – Collaborative conversations – One tactical, one strategic • Pairing should be dynamic – Members in pair switch roles • Experienced pairs may switch roles every 15-30 minutes – Change pair-up composition frequently • Pairing is not one person passively looking over other's shoulder
- 26. Mob Programming • Wholeteam works together • On the same thing • At the same time • In the same space • Using the same computer • Driver rotates • Everyone participates • Great for training & practice • Great for collaboration • Everyone up to speed faster • Some teams mob always, others frequently • Features delivered faster – single piece flow /wo handoffs 1
- 27. 3 Rules ofTest Driven Development 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. With tests you are in control; without tests you aren’t! Bob Martin - The Three Rules of TDD
- 28. Refactoring Changing the internalstructure of code to make it easier to understand and modify Without changing any of the external behavior Because you have only changed the internal code structure and not its external behavior, your tests should still pass after refactoring. Run them to make sure. For more information on Refactoring see “Refactoring” by Martin Fowler
- 29. Test Driven DevelopmentFeedback Loop Write a test for new low level functionality Run the test and watch it fail (no code = test fails) Write just enough code to make the test pass Run the test and watch it pass Clean up complex or messy code Run test again to make sure it still passes Check in Code & Tests Check in Code & Tests
- 30.
- 31. FizzBuzz Kata Simulates achildren’s math game: • Develop tests and a method that given an integer (or int) input returns Fizz if the number is divisible by 3, Buzz if divisible by 5 and otherwise returns the number, e.g.: • Next modify the method to return Whizz if divisible by 7, e.g. : 1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBuzz 16 17 Fizz 19 Buzz 21 Etc. 1 2 Fizz 4 Buzz Fizz Whizz 8 Fizz Buzz 11 Fizz 13 Whizz FizzBuzz 16 17 Fizz 19 Buzz FizzWhizz etc.
- 32. FizzBuzz Kata (continued) Continuemodifying FizzBuzz to: • Return Fizz if the number is divisible by 3 or if the number contains a 3, e.g. 6, 13 and 31 return Fizz • Next modify the method to return Buzz if divisible by 5 or contains a 5 e.g. 10 and 52 return Buzz, while 51 returns FizzBuzz • Next modify the method to return Whizz if divisible by 7 or contains a 7 e.g. 14, 17 and 71 return Whizz, while 72 returns FizzWhizz
- 33. Coin Changer Kata Simulateproviding change for 1 to 99 cents: • Develop tests and a method that given an integer (or int) returns the minimal number of coins to make that change. • Use this version of Coin Change kata (it’s simpler), instead of the one that asks for all possible combinations. • Coins are quarters, dimes, nickels and pennies. Ignore half dollars. • Before starting, choose a way to represent the coins. Either as an array of strings [“quarter”, “dime”, “dime”, “penny”] or as single string “QDDP”, e.g.: 1 -> [“penny”] or “P” 2 -> [“penny”, “penny”] or “PP” 67 -> [“quarter”, “quarter”, “dime”, “nickel”, ”penny”, ”penny”] or “QQDNPP”
- 34. Roman Numeral Kata ThisKata has at least two parts: Converting Arabic numbers (e.g. integers) to Roman Numerals and converting Roman Numerals to Arabic Numbers. The Romans had no negatives, 0 or above 3,999. Start with the Arabic to Roman. Arabic to Roman • Develop tests and a method that given an Arabic number (integer or int) returns equivalent Roman Numeral. Roman to Arabic • Develop tests and a method that given a Roman Numeral returns equivalent Arabic number (integer or int) .
- 35. Roman Numeral Kata(continued) • Don’t assume that all developers know the Roman Numeral system. Start this kata, by going over the Roman Numeral system. • Extra credit: after completing both katas, consider writing behavioral tests in Cucumber for a tool that converts both ways like https://www.romannumerals.org/converter 1 -> I 2 -> II 3 -> III 4 -> IV 5 -> V 6 -> VI 7 -> VII 8 -> VIII 9 -> IX 10 -> X 20 -> XX 30 -> XXX 40 -> XL 50 -> L 60 -> LX 70 -> LXX 80 -> LXXX 90 -> XC 100 -> C 200 -> CC 300 -> CCC 400 -> CD 500 -> D 600 -> DC 700 -> DCC 800 -> DCCC 900 -> CM 1000 -> M 2000 -> MM 3000 -> MMM 39 -> XXXIX 246 -> CCXLVI 207 -> CCVI 1066 -> MLXVI 1776 -> MDCCLXXVI 1954 -> MCMLIV 1990 -> MCMXC 2018 -> MMXVIII 3999 -> MMMCMXCIX
- 36.
- 37. 37 Bibliography • “The CodingDojo Handbook” by Emily Bache ISBN 9789198118032 Hardcopy: Amazon, Lulu, etc. , PDF: https://leanpub.com/codingdojohandbook • “Mob Programming: A Whole Team Approach” by Woody Zull and Kevin Meadows Lean Pub http://leanpub.com/mobprogramming • “Pair Programming Illuminated” by Laurie Williams and Robert Kessler ISBN 0-201-74576-3 • “Extreme Programming Explained (second edition)” by Kent Beck and Cynthia Andres ISBN 0321278658 • "Extreme Programming Installed” by Ron Jeffries, Ann Anderson and Chet Hendrickson : ISBN 978-0201708424
- 38. 38 Bibliography (continued) • “TestDriven Development by Example” by Kent Beck ISBN 0321146530 • “Test-Driven Development: A Practical Guide” by David Astels ISBN 978-0131016491 • "Refactoring" by Martin Fowler: ISBN 0201485672 • "Refactoring Workbook" by William C. Wake ISBN 978-0321109293 • “Clean Code” by Robert C. Martin ISBN 978-0132350884 • “Working Effectively with Legacy Code” by Michael Feathers ISBN 978-0131177055
- 39. 39 Webliography • Advice onRunning Katas https://alastaircrabtree.com/tips-for-running-a-code-kata-at-work/ • Kata Advice from Dave Nicolette https://davenicolette.wordpress.com/2012/07/25/why-should-we-do-code-katas • Interesting Kata Resources http://www.corporateprogrammer.com/blog/code-katas/ • Mob Programming https://www.agilealliance.org/resources/experience-reports/mob-programming- agile2014/ • JUnit Test Infected: http://junit.sourceforge.net/doc/testinfected/testing.htm • Test Driven Development Community: http://www.testdriven.com/ • 4 Rules of Simple Design https://martinfowler.com/bliki/BeckDesignRules.html • The Once and Only Once Principle: http://c2.com/cgi/wiki?OnceAndOnlyOnce • Martin Fowler on Problems with Repetition: http://www.martinfowler.com/ieeeSoftware/repetition.pdf • Transformation Priority Premise (test order to promote evolving code design) https://8thlight.com/blog/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html
- 40.
- 41. 41 Example Kata Subjects •Prime Numbers Kata • Prime Factors Kata • Berlin Clock • Chutes and Ladders • Craps Kata • Harry Potter Kata • Ordered Jobs Kata • Pacman Kata • Movie Ticket Discounts • Mastermind Kata • Vending Machine Kata • Battleship Kata • Word Wrap kata • Credit Card Number Validator
- 42. 42 General Kata Links •https://github.com/gamontal/awesome-katas#gaurav-aroras-tdd- katas-collection • http://codekata.com/ • https://github.com/gigasquid/wonderland-clojure-katas • https://github.com/garora/TDD-Katas • http://codingdojo.org/kata/ • https://github.com/devdrops/Katas Multiple Katas:
- 43. 43 Business Rules KataLinks • http://codekata.com/kata/kata01-supermarket-pricing/ • http://codekata.com/kata/kata09-back-to-the-checkout/ • http://codekata.com/kata/kata16-business-rules/ • http://codekata.com/kata/kata17-more-business-rules/ • https://stefanroock.wordpress.com/2011/03/04/red-pencil-code- kata/ • http://www.simoraman.com/code-kata-business-id-validation • https://www.codewars.com/kata/validate-credit-card-number • https://handcraftsman.wordpress.com/2010/06/23/tdd-code- kata-credit-card-number-validator/
- 44. 44 Refactoring Kata Links •https://github.com/emilybache/GildedRose-Refactoring-Kata • https://github.com/emilybache/Tennis-Refactoring-Kata • https://github.com/emilybache/Yatzy-Refactoring-Kata • https://github.com/emilybache/Parrot-Refactoring-Kata • https://github.com/philipschwarz/refactor-prime-generator-to- clean-code-kata-java/tree/master/src/primes • https://github.com/neopragma/java-legacy Refactoring Katas start with code. Most of these Katas have starting code in multiple languages. Before starting on a Refactoring Kata, be sure to write automated unit tests that cover the code.
- 45. 45 Mock Objects KataLinks • https://github.com/emilybache/Racing-Car-Katas • http://osherove.com/tdd-kata-2/ • https://www.planetgeek.ch/2010/03/28/mocking-kata-instrument- processor-net/ • https://www.planetgeek.ch/2010/03/31/mocking-kata-copier-net/ Multiple languages starting code, add tests and enhance: Other Katas requiring Mock Objects
- 46. 46 Some Kata VideoLinks Collections of Kata videos: Transformation Priority Principle – Prime Numbers Example: Transformation Priority Principle – Numbers in Words Example: Transformation Priority Principle – Roman Numerals Example: • http://katas.softwarecraftsmanship.org/ • http://katas.softwarecraftsmanship.org/archive • https://vimeo.com/channels/tga12/53829152 • https://vimeo.com/97516288 • https://www.infoq.com/presentations/tpp-tdd • http://katas.softwarecraftsmanship.org/post/38470416869/roma n-numerals-kata-with-corey-haines-this-is-the