효율적프로그래밍열린세미나

여러분들이 세미나실을 나설 때에

• TestFirstProgramming을 이해하고, 할 줄 알며
  
• PairProgramming을 효과적으로 할 수 있고
  
• CrcCard 방법으로 디자인 토론을 할 수 있으며
  
• 이 코드(디자인)와 저 코드(디자인)가 있을 때 무엇이 어떤 면에서 더 나은지 생각해볼 수 있고
  
• 나쁜 코드, 나쁜 디자인을 개선하는 방법을 알고, 적용할 수 있으며
  
• 객체를 단순히 행동과 정보의 결합으로 생각하는 저차원에서 벗어나 "책임" 중심으로 사고하고 디자인에 적용할 수 있고
  
• 문제를 여러명이 함께 해결하는 방법과
  
• 공동 학습을 체험해 보고 또 이를 적용할 수 있는 능력을 키워드리는 데
  

에 목표를 둡니다만, 무엇보다도

• 한번 재미있고 유익하게 놀아보자 (소위 지적 유희라고 하는)
  
  

는 것도 목표의 하나입니다.

제1회 파이썬 작은세미나 에서의 내용과 일치하는 부분이 조금 있지만, 실질적인 부분을 많이 다루고, 개발 방법론 내용을 줄이고, 조금 수준을 낮춰서 문법에는 익숙하지만 프로그래밍을 제대로 해본적 없는 사람에 맞춘 강의입니다. 또 사람이 적은 것을 적극 활용해서 토론과 실습 중심으로 진행합니다. (그렇다고 대부분의 한국적 문화에서 벌어지는 지루하고 고리타분한 그런 스터디가 아니고) 혹시 게임처럼 재미있게 느껴질 수도 있습니다. You will experience a new way of learning!

일단 PairProgramming의 기본 개념, 원리, 원칙, 효과 등을 생산성, 효율성, 심리적 효과 등의 측면에서 살펴보고 제가 경험한 것, 관찰한 것을 토대로 팁, 테크닉을 전수합니다. 제가 만든 RecordYourCommunicationInTheCode나 DialgoueWhilePairProgramming 등도 국내 최초(!) 소개됩니다. 실습 위주

• UnitTesting in Python
  
• Python specific unittesting patterns
  
• Using Debuggers with UnitTesting framework as the last resort
  
  

파이썬에서 유닛테스팅을 하는 방법과 design 및 analysis로서의 테스팅을 설명합니다. 그리고, 왜 "TestFirstProgramming 에서 테스트가 테스트가 아닌지" 이야기 합니다. (DiveIntoPython이라는 꽤 유명한 문서에 유닛테스팅이 소개되어 있는데 거긴 테스트가 테스트에서 끝납니다. 유닛테스팅 위력의 1/10도 활용 못하는 셈이죠.) 그리고 파이썬에서 자주 사용되는 (아니, 제가 경험적으로 만들어 낸) 테스팅 패턴을 알려드립니다.

• ReFactoring as a way of understanding codes
  
• ReFactoring Legacy Codes
  
  

리팩토링 개념 소개와 BadSmell에 대해 말씀드리고, SimpleDesign에 대해 이야기 합니다. 그리고, "아름답다, 간단하다"고 하는 것의 기준에 대해 논의합니다. (최근 KentBeck의 입장 변화와 함께). 그리고, 레거시 코드(기존에 이미 있던 코드) 리팩토링을 하는 방법, 유닛테스트가 없는 상황에서 리팩토링을 하려면 테스트 코드가 필요하고, 테스트 코드를 만들려면 리팩토링을 해야하는 catch-22 상황을 극복하는 법을 알려드립니다.

어휘교습에는 항상 등급별어휘목록이라는 것이 필수적입니다. 자주 쓰이는 단어부터 배워야 효과적인 것이죠. 마찬가지로 DP에서도 자주 쓰이고 더 유용한 패턴을 먼저 배워야 합니다. (실제로 GoF 들도 강의를 할 때 이렇게 합니다. 자신들의 책 DP는 스스로도 레퍼런스 북이라고 인정합니다.) 리팩토링을 할 때 그 목적지 안내에 도움이 될 유용한 패턴을 소개합니다. MicroDesignPatterns는 GoF DP보다 작은 레벨의 DP를 말합니다.

아마 이게 빠지고 OOP개념 설명이 들어갈 듯 합니다.

아직 국내에는 소개되지 않았는데, Wirfs-Brock이라는 사람이 만든 디자인 방법론입니다. 다음의 CrcCard와 짝을 이룹니다.

XP를 만든 KentBeck과 Wiki를 만든 WardCunningham이 함께 만든 디자인 방법입니다. 역시 국내에는 소개되지 않았습니다.

이상의 내용들이 너무 많은 것 아니냐는 생각을 하시는 분들이 많겠는데, 모두 개별적으로 소개된다기 보다는 상호 연계된 "네트워크"로 소개가 될 겁니다. 그리고 실습을 할 때 이 대부분을 함께 엮어서 직접 "사용해" 볼 기회가 있습니다. 이걸 해보면 실제로 뭔가 할 수 있는 능력이 생길 겁니다.

실습시에는 ResponsibilityDrivenDesign을 통해 문제 분석을 하고 디자인을 하며, 그걸 CrcCard를 통해 의논하고, 기록하며 (UML Class Diagram의 약형도 사용 가능), 이걸 PairProgramming을 통해 TestFirstProgramming으로 작성하고, 이 중에 ReFactoring을 해 나가면서 필요에 따라 MicroDesignPatterns를 도입해 가면서 디자인을 점진적으로 개선해 나가고, 모든 유닛테스트를 통과하는 순간 마칩니다.

마친 후에는 각 팀(두 사람 씩)이 만든 코드를 놓고 모든 사람이 Code Review를 하고 논의를 합니다. 바둑의 복기처럼. 이렇게 하면 더 좋지 않았을런지, 저긴 왜 저렇게 했는지, 아까 팀이랑 지금 팀이랑 이건 유사하다 이건 다르다 등. 대단한 경험이 될 겁니다. 얼마나 많이 배울 수 있는지.

기본적으로 이 세미나는 "문제 해결 능력의 진작"을 일차적 목표에 둡니다.

Python : Life is too short! You Need Python!

IDLEFORK at http://www.python.org (표준 패키지에 따라오는 IDLE을 써도 큰 상관은 없지만 매번 save, import, reload가 필요해서 조금 불편함)

• 7호선 학동역 부근 yong27님 회사
  
• 10월 10일
  
• 시간은 7-10시 (2시간 강의, 1시간 실습)
  
  

• 제한 없습니다.
  
  

• PairProgramming 을 위해서 참여인원의 반수 이상의 컴퓨터가 필요합니다. 만약 이것이 안되면, 컴퓨터를 빌려서 setting 을 해야 하는데 문제가 좀 복잡해집니다.
  
• 노트북 있으신 분은 노트북 가지고 오셨으면 합니다. Python 깔아서요. 밑에 check 해주세요.
  
• 익숙한 파이썬 서적이 있으면 가져 오시고, 파이썬을 설치하면 같이 깔리는 HTML 파일(Library Reference)이 도움이 될지도 모르겠습니다.
  
• Python 2.1부터 UnitTest 가 포함되는 관계로 노트북에 Python 2.0을 깔아서 오시면 아니 됩니다. 2.0 깔린 경우에는 2.1 이상으로 upgrade 해 주세요.
  
• IDLEFORK
  

• OOP가 2이하인 분
  
  • Object, Class, Inheritance, Polymorphism, Method, Attribute, Encapsulation 등에 대한 개념적 이해 (apprx. 1hr)
    
    • http://catalog.com/softinfo/objects.html
      
    • http://disc.cba.uh.edu/~rhirsch/spring97/lam1/hope.htm
      
    • 책을 구입한다면
      
      • (영광의 JoltAward에 빛나는) Page-Jones의 Fundamentals of Object-Oriented Design in UML이나
        
      • Timothy Budd의 An Introduction to Object Oriented Programming 혹은
        
      • Lau의 The Art of Objects : Object-Oriented Design and Architecture
        
      • RDD를 만든 Rebecca Wirfs-Brock의 Designing Object-Oriented Software
        
      • 감동적인, Chamond Liu의 Smalltalk, Objects, and Design
        
      • 가능하면 언어독립적이고 OOP의 개념적인 설명이 풍부한 책이 좋은 책임. news:comp.object FAQ 참고
        
• Python이 2이하인 분
  
  • Python의 기본 자료형, 문법, 모듈 개념, 특히 Python OOP의 이해 (apprx. 1h30m 가능하면 집중적으로 빨리 전체를 훑을 것)
    
    • http://www.crosswinds.net/~agauld/
      
    • http://www.hetland.org/python/instant-hacking.php
      
    • http://www.hetland.org/python/instant-python.php
      
    • http://www.ibiblio.org/obp/thinkCSpy/
      
    • http://www.python.org/doc/current/tut/node11.html
      
    • 책을 구입한다면
      
      • 다른 언어에 익숙한 분은 일단 Python Tutorial을 보시고
        
      • 초보 프로그래머들은 Learning Python이나, Quick Python Book을 추천
        
        

위의 자료를 모두 읽어보라는 것이 절대 아니고, 자신에게 알맞는 자료를 적절히 취사 선택 하시길.

Please remember that I'm not going to teach you how to program in Python(but how to program well in whatever language) or what OOP is(instead how to get more out of OOP), since we have limited time.

• ReFactoring
  
  • CodeSmell
    
  • http://home.sprintmail.com/~wconrad/refactoring-live/smells.html
    
• TestDrivenDesign
  
  • http://www.extremeprogramming.org/rules/testfirst.html
    
  • http://www.junit.org/junit/doc/testinfected/testing.htm
    
  • XpInstalled.pdf ch.14 Test-first, by Intention
    
• PairProgramming
  
  • XpExplored.pdf ch.5 What's it like to program in pairs
    
  • http://www.objectmentor.com/s4williams.lo.pdf
    
  • http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
    
  • http://www.pairprogramming.com/conversantpairing.htm
    
  • http://www.rolemodelsoft.com/papers/ApprenticeshipInASoftwareStudio.htm
    
• CrcCard
  
  • http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc/
    
  • http://c2.com/doc/oopsla89/paper.html
    
• ResponsibilityDrivenDesign
  
  • ResponsibilityDrivenDesign.pdf
    
    

참가를 하실 분들은 성함과 이메일 주소를 여기 남겨주세요. 선착순(최대) 15명

번호	이름	이메일	노트북지참여부	OOP	Python	비고	group	pair
1	서지원	jiwon@softwise.co.kr	.	2.5	2		2	C
2	지상은	mtmind@no-smok.net	가능	1.5	2	.	3	E
3	김형용	yong27@no-smok.net	가능	2.2	2.5	yong27	1	A
4	김승범	picxenk@dreamwiz.com	.	2	2	.	2	C
5	이혜원	glanze@chollian.net	.	1.5	2	sefiroth	1	B
6	타레	tarepnda@yahoo.co.kr	.	2	1	본명인가요?	2	G
7	한금성	makegold@hanmail.net	불가	0.5	0.7	금성	2
8	조선환	remain@orgio.net	가능	2	2	환이	1	A
9	윤창필	reiot@hanmail.net	가능	2	1	레이옷	3	D
10	오진원	ohjw@postech.ac.kr	.	2	1	digitobi	1	B
11	채희상	theand sogang ac kr	불가	1.5	2	희상	2	D
12	김치화	BIG04@lycos.co.kr	가능	1.5	2	sefiroth	1	G
13	윤영식	sigi@darkeden.com	불가	2	1		3	F
14	김재우	evacuee@kldp.org	가능	2.5	2.5	.	3	E
15	.	.	.	.	.	.	3	F

죄송합니다. 장소가 너무 협소하고, 실습 컴퓨터가 마련되지 않는 관계로 더 이상의 신청을 받을 수 없음을 이해해 주시기 바랍니다. --지상은

OOP이해도 (소숫점 가능 e.g. 1.5, 3.9, ...) : 세미나 수준 및 짝짓기에 참고

1. 생소하거나 대충 개념만 알고 있다.
   
2. 최소 하나 이상의 언어로 OOP를 해 본적 있거나, 남에게 OOP를 개념적으로 설명해 줄 수 있다. (class, object, method, attribute, inheritance, polymorphism, encapsulation 등의 용어에 익숙하다)
   
3. 상속(inheritance)의 장점/단점을 실례와 함께 각각 하나 이상 말할 수 있다. (GoF나 DP가 뭔지 알고 DP를 적용하려 시도해 봤다.)
   
4. OOP의 도를 체득했다. (OOP의 음과 양을 모두 알고 있다)
   
   

Python이해도

1. 생소하거나 대충 읽을 줄만 안다.
   
2. (hello world 빼고) 원하는 프로그램을 하나 이상 만들어 본 적이 있다. (문법에 익숙)
   
3. 언제 모듈을 쓰고 언제 클래스를 써야 좋은지 말할 수 있다. (사용 패턴에 익숙)
   
4. Python의 도를 체득했다.
   
   

see also Patterns Of Learning http://www.cs.wustl.edu/~schmidt/cs242/learning.html

여기서 그룹은 디자인 단계에서 같이 토론하는 한 팀을 말하고 총 세 그룹이 있습니다. 페어는 프로그래밍 단계에서 함께 작업하는 한 쌍을 말하며 총 일곱 쌍이 있습니다. 그룹은 전체 OOP, Python 이해도의 합계가 비슷하게 되도록 배정을 했고, 페어는 두 사람 간에 차이가 크지 않으면서 초보-초보 짝은 피하는 쪽으로 했습니다. 디자인 실습에서는 다섯 사람이 한 팀이 되지만, 실제로 프로그래밍(및 전체 실습)을 할 때에는 두 사람을 한 팀으로 할 것이기 때문에 두 사람이 같은 그룹에 속할 필요는 없습니다.

그런데 OOP 개념에 익숙한 분이 얼마나 될까요? 필요에 따라 일부(MicroDesignPatterns)를 빼고, OOP 개념 설명이 들어갈 수도 있겠군요.

picxenk님 뭡니까? picxenk님이 2, 2 면 다른 사람들은 어찌 하라고...

둘 다 1 이하의 수준으로 도전해보겠다고 용감히 신청을 했습니다. 이 글을 보자마자 참석은 하고 싶었으나 바닥을 기다 못해 지하에 있는 실력때문에 계속 망설이다가 세미나 강사님이 이런 세미나를 들을 수 있는 기회의 희소성에 대해 얘기하는 걸 듣고 감히 이름을 써 넣긴 넣었는데 갔다가 괜히 민폐만 끼치지 않을까 걱정이 태산 같습니다.-_-; --금성