Header

  1. View current page

    언제나 Smile.wjp

Profile_image?t=1227427892&type=big
언제나 Smile!!
15

코딩도장(CodingDojo)

코딩도장이란?   

코딩도장은 2005년에 더 적절한 방법으로, 기술의 깊이와 정묘함을 존중하면서,

프로그래밍을 가르치고 배우는 방식을 발견하기 위한 세미나에서 시작하였습니다.

'도장'의 원래 아이디어는 미리 준비한 해결 과정의 시연을 통해 주어진 문제에 

대한 해결 방법을 개발하는 과정을 보여주는 것입니다.

코딩 도장은 결과가 아니라 과정을 시연, 의논, 개선합니다.


예를 들어, 피보나치 수열을 만드는 코드를 작성하는데,

각 페어들은 "무"에서 피보나치 수열 코드로 이르는 다양한 루트를 예컨대 TDD로 실험해

한번 해보고, 이번에는 좀 더 개선하고 세련되게 해서 다시 해보고(DoItAgainToLearn)...

하나의 행위예술이 된다. 정말 군더더기가 없다고 생각될 때까지 해본다.

그 시연 자체를 보고(결과 코드뿐만 아니라) "아름답다"고 느낄 수 있게. 그런 것들을 함께 시연하고 의논한다.

 

만약 내가 유도를 배우길 원한다면, 난 가장 가까운 도장에 등록하고, 다음 2년간 매주 1시간씩 출석을 해야 할 것이다.

그 기간이 지나고 나면, 난 아마도 기술을 발전시키기 위해 부지런히 연구하는 과정을 선택할 것이다.

몇년간 더 훈련을 하면, 검은띠를 딸 수 있을 것이고, 그것은 단지 내가 다른 배움의 단계에 도달했다는 표시에 불과한 것이다.

어떤 사범도 배우는 것을 중단할 수 없다.

만약 내가 OO프로그래밍을 배우길 원한다면, 내 고용주는 나를 큰 훈련 기관의 올해 프로그램 카타로그에서 고른,

3일 단기 자바 코스에 넣을 것이다. 그것은 참 바보같은 짓이다. 코딩 스킬을 얻는것은  일시적인 만족감의 프로세스가 아니다.

이 워크샵은 더 적절한 방법으로, 기술의 깊이와 정묘함을 존중하면서, 프로그래밍을 가르치고 배우는 방식을 발견하기 위한 것이다.

[출처] Coding Dojo(코딩 도장 - 태권도장 처럼...)|작성자 하르

코딩도장 특징

  • 코드 없이 토론하지 않는다

    책을 보고 토론하거나 하는 모임은 이미 많이 있다 (몸으로 수행하라)

  • 만든 결과물만 갖고 이야기하지 않고 만드는 과정을 직접 체험한다

    각자 만들어 온 코드만 갖고 토론하거나 하기보다 그 코드를 만든 과정을 통해 많은 것을 배운다

  • 같은 문제(카타)를 여러번 풀어본다

    정보올림피아드 같은 ProgrammingContest 준비반이 아니다. 단순한 문제풀이 스터디와 다르다. DoItAgainToLearn

  • 한가지 언어에 국한되어 있지 않다

    여러 언어를 쓰는 것에서 더 많은 학습의 기회가 있다고 믿는다.

    현재까지 코딩도장에서 사용했던 언어는 C, C++, Python, Java, Io, Haskell, Ruby, Smalltalk 등

  • 가능하면 모든 코드는 테스트 코드를 포함하도록 한다

    꼭 구현 과정이 TDD일 필요는 없으나 최소한의 테스트 코드는 있는 것이 좋다

  • 카타는 평균적인 프로그래머가 처음 풀었을 때 TDD를 사용해서 최대 1시간 내에 여유있게 풀 수 있어야 한다
  • 어려운 문제를 하나 푸는 것보다 그 시간에 쉬운 문제를 여러번 푸는 것을 장려한다.

코드도장 방법 / 사례

처음의 코딩도장( 2005년 11월)

여기 나열한 규칙과 워크샾 일정은 초안이며 이전의 세션에서 얻은 경험을 바탕으로 변경될 수 있다.

  • 코딩 도전 과제는 사전에 공지된다.
  • 비디오 스크린에 연결된 컴퓨터가 1대 있는 방이 있다.
  • 시연자는 코딩 도전 과제를 설명하고, 란도리를 청중에서 고른 2명으로 시작한다.
  • 매 5분마나 2명중 1명을 교체한다.
  • 키보드를 잡고 있는 2명은 그들이 무엇을 하고 있는지를 계속 설명해야 한다.
  • 키보드를 잡고 있는 2명은 청중중 누군가가 방향을 잃었을 경우 하던 작업을 중단해야 한다.
    그가 다시 진행중인 사항을 이해하게 되었을 경우에만, 다시 작업을 재개한다.
  • 작업을 하는 2명은 TDD(테스트기반 개발)을 사용한다.
  • 작성된 모든 코드는 아파치 라이센스 2.0을 사용해 대중에게 오픈된다.
  • 사용될 프로그래밍 언어는 세션 시작 전에 공지된다.
  • 참석할 수 있는 인원은 15명 이하로 제한한다.

Xper - 한국 eXtreme Programming 사용자 모임

짝으로 프로그래밍하며 앞에서 프로젝터를 통해 보여줄 때에는 자신이 문제를 풀어나갔던 과정을 그대로 보여준다.

수련생들은 그것을 보며 시연자들이 어떤 키배열을 쓰는지, 어떤 텍스트 편집기를 쓰는지, 어떤 순서로 프로그래밍 하는 지 등을 "고대로" 관찰할 수 있다.
참가자들이 준비할 것은: 노트북 컴퓨터(필요시 두 사람에 한 대 꼴로만 있으면 가능),

프로그래밍할 준비, 문제를 풀어보려고 노력해 봤을 것.
"관장"은 그날의 코딩도장 운영(및 사전 준비와 예약 등)을 맡는다.

시간계획(2시간 30분)
  • 코딩도장 소개 및 개인 소개 10m
  • 오늘의 문제 소개 및 몸풀기 15m
  • 한 짝이 문제를 해결하는 과정을 보여준다 30m
  • 휴식 20m
  • 각자 짝을 지어 문제의 남은 부분을 해결한다 20m
  • 최초의 짝이 문제를 마저 해결하거나 혹은 새로운 해법을 제시한다 30m
  • 토론(다음 코딩도장 때는 어떻게 할까)과 한담(최근의 깨달음과 고민, 자신의 수련 이야기 등) 20m
  • 버퍼 5m

필통 코딩도장

  • 현재 운영되고 있는 코딩도장으로 매주 목요일 저녁에 오프라인 모임으로 진행
  • 운영 방법

    • 문제를 3-4일전에 홈페이지에 공고 코딩도장 인원 모집

      • 문제조차 안 읽은 경우도 많다.
      • 2명당 1개정도 노트북으로 페어프로그래밍을 할 수 있도록 준비한다. ( 개인 노트북을 가져온다 )
    • 풀이는 반드시 짝 프로그래밍으로 합니다. 짝 프로그래밍을 하지 않는다면 굳이 모임을 가질 이유가 없다고 봅니다.
    • 모임 시간은 장소의 문제도 있고 해서 2시간입니다. 대략 1시간 정도를 문제 풀이에 사용합니다.

      • 그렇게 난이도 있는 걸 다루지 않는다.
    • TDD는 강제하지 않지만, 대부분 TDD로 풉니다.
    • 프로그래밍 언어나 프레임웍은 알아서 결정해서 풉니다.
    • "코딩 수련"을 한다면 일부러 업무용으로 사용하지 않는 언어를 택할 것을 권한다.

      • 일부러 다른 언어를 택하는 건 언어는 사고에 강력한 영향을 주기 때문이다.
  • 회고

    • 소감
    • 배운 점
    • 좋았던 점
    • 개선 점

MAIET STORY( 건즈 개발팀 )

  • 월요일 점심시간에 운영
  • 운영 방법

    • 문제 하나당 2주일 소요(매주 월요일 점심 시간에 모임을 갖는다.)
    • 첫 날은 문제를 각자 미리 풀어와서 해법과 코드를 돌아가면서 설명한다.
    • 토론을 통해 그 문제의 최적 알고리즘을 정한 후, 각자 작성한 코드 중에서 해당 문제에 대한 최고의 코드를 함께 만들기 위해
    • 리팩토링할 코드 대상을 선정한다. (의견을 모아 다수결로 결정. 최고의 코드가 선택될 수도 있고, 최악의 코드가 선택될 수도 있다.)
    • 두번째 날, 선택된 코드를 리팩토링할 사람을 랜덤으로 선택한다.

      그 사람이 주도권을 쥐고 리팩토링하되, 다른 사람들은 적극적으로 리팩토링에 대한 의견을 낸다.

    • 한사람당 20분 정도씩 시간을 정해서 다함께 페어로 돌아가면서 리팩토링한다.
      다음에 리팩토링할 사람도 물론 랜덤으로 선택한다.
    • 리팩토링시 몇가지 규칙

      • 키보드를 잡고 있는 사람이 주도권, 컨벤션 등은 초기 코드 작성자에 맞춰준다.

효과/경험

  • 거울 효과
    동료 개발자들의 공개 코딩을 실시간으로 관찰하면서 자신의 모습을 발견함.
  • 파트너와 효과적으로 의사소통하는 방법

    • 코드로 옮기기 전 간단히 의견을 정리하고 합의하는 과정에서는 설계스케치가 효과적일 것입니다. 다만, 설계스케치가 장황한 설계로 이어지면 불필요한 토론으로 시간을 잡아먹는 경우가 많으니 동그라미, 화살표, 키워드 정도만으로 설계를 표현해보는 연습이 중요합니다
    • 함수 등을 새로 정의할 때는 가급적이면 어떻게 구현할 것인가 보다는 어떻게 사용할 것인가에 초점을 맞추면 좋습니다
      이미 쓰임새가 코드로 표현되어 있기때문에 단순히 말로써 이러이러한 함수를 작성하자고 할때보다 훨씬 명확하고 전달이 용이합니다

출처링크

Tags

History

Last edited on 08/20/2009 17:58 by Smile.wjp

Comments (0)

You must log in to leave a comment. Please sign in.