'Code Kata'에 해당되는 글 2건

  1. 2008/04/09 # Code Kata Background
  2. 2008/01/16 # Code Kata (1)
2008/04/09 20:37

# Code Kata Background

Code Kata

Background

How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes practicing; applying the theory over and over again, using feedback to get better every time.

How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and hours every day, practicing.

But in the software industry we take developers trained in the theory and throw them straight in to the deep-end, working on a project. It’s like taking a group of fit kids and telling them that they have four quarters to beat the Redskins (hey, we manage by objectives, right?). In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.

CodeKata:
A description of how this all started
MoreKata:

Sometimes ‘kata’ isn’t quite the right word; karate uses other techniques to teach too.

The Kata

What makes a good practice session? You need time without interruptions, and a simple thing you want to try. You need to try it as many times as it takes, and be comfortable making mistakes. You need to look for feedback each time so you can work to improve. There needs to be no pressure: this is why it is hard to practice in a project environment. it helps to keep it fun: make small steps forward when you can. Finally, you’ll recognize a good practice session because you’ll came out of it knowing more than when you went in.

Code Kata is an attempt to bring this element of practice to software development. A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer. I add a new kata every week or so. Invest some time in your craft and try them.

If you want to discuss kata, there’s a mailing list here, and a wiki here. However, remember that the point of the kata is not arriving at a correct answer. The point is the stuff you learn along the way.

KataOne: Supermarket pricing. Pricing looks easy, but scratch the surface and there are some interesting issues to consider.
KataTwo: Karate Chop. A binary chop algorithm is fairly boring. Until you have to implement it using five totally different techniques.
KataThree: How Big, How Fast? Quick estimation is invaluable when it comes to making design and implementation decisions. Here are some questions to make you turn over the envelope.
KataFour: Data Munging. Implement two simple data extraction routines, and see how much they have in common.
KataFive: Bloom Filters. Implement a simple hash-based lookup mechanism and explore its characteristics.
KataSix: Anagrams. Find all the anagram combinations in a dictionary.
KataSeven: Reviewing. What does our code look like through critical eyes, and how can we make our eyes more critical?
KataEight: Objectives. What effects do our objectives have on the way we write code?
KataNine: Checkout. Back to the supermarket. This week, we’ll implement the code for a checkout system that handles pricing schemes such as "apples cost 50 cents, three apples cost $1.30."
KataTen: Hash vs. Class. Is it always correct to use (for example) classes and objects to structure complex business objects, or couple simpler structures (hash as Hashes) do the job?
KataEleven: Sorting it Out. Just because we need to sort something doesn’t necessarily mean we need to use a conventional sorting algorithm.
KataTwelve: Best Sellers. Consider the implementation of a top-ten best sellers list for a high volume web store.
KataThirteen: Counting Lines. Counting lines of code in Java source is not quite as simple as it seems.
KataFourteen: Trigrams. Generating text using trigram analysis lets us experiment with different heuristics.
KataFifteen: Playing with bits. A diversion to discover the pattern in some bit sequences.
KataSixteen: Business Rules. How can you tame a wild (and changing) set of business rules?
KataSeventeen: More Business Rules. The rules that specify the overall processing of an order can be complex too, particularly as they often involve waiting around for things to happen.
KataEighteen: Dependencies. Let’s write some code that calculates how dependencies propagate between things such as classes in a program.
KataNineteen: Word chains. Write a program that solves word chain puzzles (cat -> cot -> dot -> dog).
KataTwenty: Klondike. Experiment with various heuristics for playing the game Klondike.
KataTwentyOne: Simple Lists. Play with different implementations of a simple list.

There are places (apart from the comments in this blog) where you can discuss Code Kata.

The first is a YahooGroups mailing list, the second an index page on the PragProg wiki.

I have to admit that I’m nervous doing this. My hope is that folks will work on the kata for a while before discussing them; much of the benefit comes from the little "a-ha!" moments along the way. So, it’ll be interesting to see how (and if) the discussion develops.

크리에이티브 커먼즈 라이선스
Creative Commons License

'Programming > Code Kata' 카테고리의 다른 글

# Code Kata One  (0) 2008/04/09
# Code Kata Background  (0) 2008/04/09
Trackback 0 Comment 0
2008/01/16 15:58

# Code Kata

# " 사랑하지 않으면 떠나라! " 는 책을 읽으면서 개발자들이 이론, 코딩등 연습을  할 수 있는 것들이 필요하다는 얘기가 나온다.
  악기 연주자들은 전문가가 되기 위해서 끊임없이 연습하고 노력해서 실제 공연에 연습한 만큼의 결과가 나오는데 개발자들은 악기 연주자들의 실제 공연과 같은 프로젝트를 진행하고 있는 회사에서 연습을 하고 있으니 자기 발전이 없다는 얘기가 나온다.
  이에 개발자들도 공연에서 진정한 실력을 발휘하기 위해 연습이 필요한데 이런 연습을 할 수 있는 여러가지 자료 중에 Code Kata 를 추천하고 있다.

# 21개의 문제를 다 풀어봐야 되는데.. 얼마나 시간이 걸릴지 모르겠음.... ^^;

# http://codekata.pragprog.com/

Background

How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes practicing; applying the theory over and over again, using feedback to get better every time.

How do you get to be an All-Star sports person? Obviously fitness and talent help. But the great athletes spend hours and hours every day, practicing.

But in the software industry we take developers trained in the theory and throw them straight in to the deep-end, working on a project. It’s like taking a group of fit kids and telling them that they have four quarters to beat the Redskins (hey, we manage by objectives, right?). In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.

크리에이티브 커먼즈 라이선스
Creative Commons License

'Programming' 카테고리의 다른 글

# NPTL  (0) 2008/05/29
# [JAVA] byte형 변수를 부호비트를 무시  (0) 2008/05/06
# Code Kata  (1) 2008/01/16
# CVS command list  (0) 2007/10/24
# Ship it! 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드  (0) 2007/10/11
# 프로그래머와 유치원생  (0) 2007/06/12
Trackback 0 Comment 1