This repository is a mix of Papers We Love and katas: a place where to store katas for future reference.

• Create a new header (h3 - ###) with the title.
• Create a human-readable description as the body of the element
• Create a Tags element specifying any information about the kata, in machine readable form:
  • comma-separated tags
  • all lowercase
  • prefer using nouns (rather than verbs)
  • Suggestion:
    • include the topic
    • the author
    • what to learn
    • what to practice
    • the programming language
    • the size of the exercise
    • and anything else that comes to your mind

Take a legacy codebase and refactor to separate the concerns.

The code is small enough to be understood at once, but big enough to add validation, input and output, side effects.

Plus:

• Use only automatic refactorings until you have broken the dependencies

Tags: legacy-code, richard-dalton, c-sharp, automatic-refactoring, one-day, dependency-breaking-technique, any-language

These kata illustrate some techinques we can use to stabilize legacy code—the code that works, DON'T TOUCH IT.

Tags: legacy-code, extract-and-override, static-cling, sprout-method, interface-indirection, john-fazzaro, warren-barnes, j-d-gomes, dependency-breaking-technique

An incremental kata to replace some numbers with others, following some rules.

This kata is ideal to practice Rules and Rule Engine

Tags: incremental-kata, rule, business-rule, gianfranco-alongi, number, algorithm, business-code

A refactoring kata with nearly perfect code coverage in which the feature envy smell is very strong. Almost all behavior is separated from its data and the domain is anemic.

Tags: refactoring, gabriele-tondi, tell-dont-ask, design-principle, solid, value-object, object-orientation, oop, feature-envy, code-smell, anemic-domain

A classic legacy-code kata by Martin Fowler.

A 1/2 to 1 day exercise

Tags: refactoring, martin-fowler, classic, video-store, solid, code-smell, object-orientation, oop, half-day, one-day

A legacy-code kata by Emily Bache.

The purpose is to add a new feature to a legacy code, with the [optional] restrictions of not changing some elements in the classes.

Tags: legacy-code, emily-bache, github, example, constraint, restriction, c, groovy, java, spock, kotlin, r, smalltalk, typescript, abap, c99, clisp, cpp, csharp, dart, elixir, fsharp, go, haskell, js, perl, perl6, php, plsql, python, ruby, rust, scala, swift

A greenfield kata to practice specialization and some business rules.

The purpose is to build a new system that can greet differently based on the input.

This Kata is designed to help practice what a test of a pure function ought to look like. It is intentionally designed to start with a very easy, non-branching base case which slowly becomes addled with complexity as additional requirements are added that will require significant branching and eventually a pressure to compose additional units.

This Kata was suggested by Nick Gauthier and inspired a bit by Bob from Exercism.

This Kata is designed to be used with Detroit-school TDD.

Tags: nick-gauthier, bob, exercism, detroit-school-tdd, outside-in, pure-function, greeting-kata, business-rule

A kata for creating a PacMan game.

The purpose is to balance the big design upfront (BDUF) with the small design upfront, finding exactly the amount of design to be effective.

Originally by William Van Den Ende

Tags: codingdojo-org, pacman, game, easy, bduf, sduf, design, ui, user-interface, ai, artificial-intelligence, pacman-kata

This repository contains the codebase that is subject to the refactoring.

Tags: refactoring, kata, java, java-8