Difference between r1.4 and the current
@@ -9,13 +9,20 @@
== 프로그램 ==
* 세미나 내용을 정리해 주세요
* 질문도 정리해 주면 좋겠네요
* 세미나 관련 자료* [https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=1pibLA94VQ8Z1cckW8IOsedbQ9joDuCwwafH93jHDgv3l-ASNn_QW2rGhxrWT&hl=en_US Refactoring Testing and Patterns]
== 후기 ==
=== 김수경 ===
* Worse is better라는 말이 인상깊었다.
* 너무 당연하게 TestDrivenDevelopment라면 테스트부터 작성해야한다고 생각하고있었는데 TDD가 반드시 TestFirstDevelopment일 필요 없다는 말을 듣고 머리를 얻어맞은 것 같았다. 테스트를 언제 작성하는지가 중요한 게 아니라 테스트를 통해 빠르게 피드백을 얻는 것이 중요.
* Floss Refactoring. 다음에 리팩토링해야지, 언제 날 잡고 리팩토링해야지가 아닌 항상 그 때 할 수 있는 리팩토링을 하자.
* Naming이 중요하다.
* 질문을 더 효과적으로 하는 법을 익히자.
후기는 차차 더 다듬어서 쓰겠습니다.
=== 김준석 ===Joseph Yoder와의 만남. 신선했다면 신선했다일까. 이렇게 빠른 외국인의 아키텍쳐설명은 들어본적이 없다. Pattern의 강자 GoF와 같이 시초를 같이 했으며 의료 분야 소프트웨어 제작에 참여하고있다고 했다.
@@ -38,7 +45,7 @@
www.hillside.net
www.adaptiveobjectmodel.com
변화 -> 추상화 이고 리펙토링이 잘못됬을 경우 그 결과를 뒤집기는 좀 힘들다고했다. 패턴을 알면 장점이 많단다. 초보자가 패턴을 아는척 하면 다친단다. 테스팅과 패턴을 초보자가 하면 좋다. Refactoring을 좀더 잘할려면 첫 걸음은 Rename부터.. 엄청난 프로그래머는 만드는것이 패턴으로 만들어질 수 있지만 대부분 그렇지 않다고 한다. 그러므로 리펙토링을 통해 수준을 높이는 훈련을 해놓는것이 좋다고한다. 그렇게 하면 의식하지 않아도 된단다.
www.adaptiveobjectmodel.com
adaptiveobjectmodel은 Joseph이 연구하고 있는 분야로 Refactoring의 상황에 맞는 방법과 패턴의 쓰임세를 지정하는 모델이다. 현재 쓰이는 것을 정리해서 했다고하고 책에서나 보던것을 좀더 정확하고 명확하게 근거있게 설명하는것 같았다. 그리고 Refactoring이 필요한 이유에 대해서는 실제로 이렇게 하면 성공을 하기 때문에 리펙토링을 하는것이 좋다고했는데 이것은 다른것에 비해 약한 근거라고했는데 그 이유는 리펙토링을 안한 더러운 코드도 성공을 하기 때문이라고 했다. 하지만 자신있게 말하자면 리펙토링을 하는것은 좋다고했다.
adaptiveobjectmodel은 Joseph이 연구하고 있는 분야로 Refactoring의 상황에 맞는 방법과 패턴의 쓰임세를 지정하는 모델이다. 현재 쓰이는 패턴을 모델화해서 정리해서 했다고한다. 책에서나 보던것을 좀더 정확하고 명확하게 근거있게 설명하는것 같았다. 그리고 Refactoring이 필요한 이유에 대해서는 실제로 이렇게 하면 성공을 하기 때문에 리펙토링을 하는것이 좋다고했는데 이것은 다른것에 비해 약한 근거라고했는데 그 이유는 리펙토링을 안한 더러운 코드도 성공을 하기 때문이라고 했다. 하지만 자신있게 말하자면 리펙토링을 하는것은 좋다고했다.
변화 -> 추상화 이고 리펙토링이 잘못됬을 경우 그 결과를 뒤집기는 좀 힘들다고했다. 패턴을 알면 장점이 많단다. 초보자가 패턴을 아는척 하면 다친단다. 테스팅과 패턴을 초보자가 하면 좋다. Refactoring을 좀더 잘할려면 첫 걸음은 Rename부터.. 엄청난 프로그래머는 만드는것이 패턴으로 만들어질 수 있지만 대부분 그렇지 않다고 한다. 그러므로 리펙토링을 통해 수준을 높이는 훈련을 해놓는것이 좋다고한다. 그렇게 하면 의식하지 않아도 된단다.
@@ -49,4 +56,26 @@
=== 서지혜 ===
* '방한기념번개모임'이라고 할걸 그랬나
* 쓰다가 날아가서 의욕이 떨어지는군..
* '방한기념번개모임'이라고 할걸 그랬나
* 쓰다가 날아가서 의욕이 떨어지는군..
* (들린) 단어 클라우드
* 패턴을 이용한 리팩토링
* big ball of mud
* facade, wrapper 패턴등을 이용해 지저분한 구현을 숨길 수 있다!
* 상아탑의 설계
* agile is good for refactoring, 애자일을 사용하면 설계도 리팩토링할 수 있다.
* selfish class
* throwaway code. 정말 한번만 쓰고 버린다. 다시는 돌아보지 말아야한다.
* merciless deadline
* 변화의 속도. 가장 느린건 platform <-> 가장 빠른건 data
* refactoring : deciplined technique
* Internal structure
* External behavior
* TDD? TFD?
* Test Driven Develope
* Test First Develope
* 교조적인 TFD X
* 테스트는 구현한 기능이 의도한대로 동작한다는 것을 검증하는 방법임. 테스트를 통해 적절한 피드백을 받을 수 있다면 된다.
1. 리팩토링 종류에 따라 테스트에 미치는 영향도
1. RENAME METHOD : LOW
1. CHANGE METHOD or STRATEGY : MEDIUM
1. 상속관계 분리, 프로시저 디자인변경, 도메인 분리, 계층구조 추출 : HIGH
=== 임상현 ===1. 소개 ¶
제4회 한국 SW 아키텍트 대회에서 기조연설을 위해 방한한 Joseph Yoder가 한국 XP 모임(http://xper.org )의 여러분들을 위해 준비한 자리입니다. 리팩토링, 테스팅, 패턴 등을 주제로 간단하게 이야기하고 토론을 할 예정입니다. 특히 패턴쪽에 경험이 많으신 분이시라, 패턴 저작, 패턴 운동의 문화 등에 대해서도 이야기를 해주시기로 했습니다. 장소대여비(토즈)를 위해 1인당 약 1~1.5만원 내외의 회비를 현장납부하셔야 합니다. 좀 더 아담하고 편안한 자리를 위해 20인 이하의 소수만 선착순으로 받습니다. 강연(영어)에 대한 통역은 제공되지 않고, 토론/질답 시간에는 순차 통역이 제공됩니다.
3.1. 김수경 ¶
- Worse is better라는 말이 인상깊었다.
- 너무 당연하게 TestDrivenDevelopment라면 테스트부터 작성해야한다고 생각하고있었는데 TDD가 반드시 TestFirstDevelopment일 필요 없다는 말을 듣고 머리를 얻어맞은 것 같았다. 테스트를 언제 작성하는지가 중요한 게 아니라 테스트를 통해 빠르게 피드백을 얻는 것이 중요.
- Floss Refactoring. 다음에 리팩토링해야지, 언제 날 잡고 리팩토링해야지가 아닌 항상 그 때 할 수 있는 리팩토링을 하자.
- Naming이 중요하다.
- 질문을 더 효과적으로 하는 법을 익히자.
3.2. 김준석 ¶
Joseph Yoder와의 만남. 신선했다면 신선했다일까. 이렇게 빠른 외국인의 아키텍쳐설명은 들어본적이 없다. Pattern의 강자 GoF와 같이 시초를 같이 했으며 의료 분야 소프트웨어 제작에 참여하고있다고 했다.
처음에 더러운 코드를 뜻하는 Big Ball of Mud에 대해 얘기했는데 첨에는 못알아듣다가 텍사스에서 땅값이 비싸서 멋진 아키텍쳐로 높게 지은 빌딩과 얽기설기 있는 브라질의 판자촌을 보고 깨달았다. 나는 그저 메모리도 많이쓰고 비싼 땅값을 주는곳에서 쓰지못하는 판자촌 짓는 사람이라고. 젠장 땅값 적게 나가게 집을 올려야지.
리펙토링 기본 기법에 관해서는 기본적으로 Rename과 함수 분할 등을 Martin Fowler이 지은 Refactoring책을 통해 알수있다고 했다 이러한 리펙토링을 이용하여 청소할 수 있고 리펙토링은 중요하다고 했다. 이거 좋군. 딱 들은 생각. 우선 리펙토링할때는 이름이 최우선적으로 다루어져야한다고 했는데 가장 설명하기 좋고 듣기도 편했던 부분이다. 그 이유는 이름부터가 단축이면 못알아먹기 때문에~~~!! 이라고했다. 그래서 나는 앞으로 길더라도 의미가 되는 단어를 쓰기로 결심했다. 괜히 이름 단축시키지 말자고.
일단 코드 컨스트럭트를 할때는 Facade and Wrapper Pattern을 이용해서 방을 청소하고 시작하라고하는것도 보았다. 하긴 이렇게하면 다른것에 상관 없이 쓸수 있겠군? 이라고 생각했다.
Test기법에 관해 캔트백의 예를 들며 말해줬는데 코드를 만들때는 되게하고, 완성하고, 최적화시키는 순서로 만들라고했다. 그래서 난 더럽게 우선 돌아가게 짠다. 고 위안했다. Test가 되게 하고 Refactoring을 하고 다시 돌아가게 하고. 순환관계를 다시 보기도했다. 그렇게 하면 영향이 덜가고 잘 돌아가겠지? 라고 생각했다.
Refactoring과 Pattern은 누가 누구에 속한 관계가 아니라서 적절히 써야한다고했다. 교집합이었다 그림은. 그래 적절히 써야지라고 생각했다.
강조했던것은 Agile과 Refactoring의 상관관계였는데 둘다 얽히면 굉장한 시너지를 내기 때문에 목적은 달라도 병행해서 쓰면 좋다고했다. Agile을 지금 쓰는 사람 있냐고 물어봤는데 손들기는 뭐했다. Face-to-Face, pair 프로그래밍. Communication 만세다! Agile기법에 대해 Refactoring에 대해 자신의 이념, 이상이 들어간 코드를 만드는 프로그래머가 반대를 한다면 Pair프로그래밍을 통해 '너만의'코드가 아닌 '우리'의 코드라는것을 인식시켜주는게 좋다고 했다. 근데 그런사람이 있을까? 여튼 경험에 우러나온 대답같았다.
참조할 사이트는 다음과 같았다.
www.hillside.net
www.adaptiveobjectmodel.com
www.adaptiveobjectmodel.com
adaptiveobjectmodel은 Joseph이 연구하고 있는 분야로 Refactoring의 상황에 맞는 방법과 패턴의 쓰임세를 지정하는 모델이다. 현재 쓰이는 패턴을 모델화해서 정리해서 했다고한다. 책에서나 보던것을 좀더 정확하고 명확하게 근거있게 설명하는것 같았다. 그리고 Refactoring이 필요한 이유에 대해서는 실제로 이렇게 하면 성공을 하기 때문에 리펙토링을 하는것이 좋다고했는데 이것은 다른것에 비해 약한 근거라고했는데 그 이유는 리펙토링을 안한 더러운 코드도 성공을 하기 때문이라고 했다. 하지만 자신있게 말하자면 리펙토링을 하는것은 좋다고했다.
변화 -> 추상화 이고 리펙토링이 잘못됬을 경우 그 결과를 뒤집기는 좀 힘들다고했다. 패턴을 알면 장점이 많단다. 초보자가 패턴을 아는척 하면 다친단다. 테스팅과 패턴을 초보자가 하면 좋다. Refactoring을 좀더 잘할려면 첫 걸음은 Rename부터.. 엄청난 프로그래머는 만드는것이 패턴으로 만들어질 수 있지만 대부분 그렇지 않다고 한다. 그러므로 리펙토링을 통해 수준을 높이는 훈련을 해놓는것이 좋다고한다. 그렇게 하면 의식하지 않아도 된단다.
여러모로 Refactoring에서 나오는 Pattern과 Holub이 주장하는 Design Pattern과는 많았고 옆에서 계속 번역해주시는 창준선배님을 보면서 참 나도 영어 듣기가 녹슬었구나 하는 생각이 들었다. FPS에서 영어를 배워봐야하나. 여러사람이 다양하게 생각하는 Refactoring과 Pattern에 대해 다시한번 좀더 연구할 생각이드는 시간이었다.
- 후기 정말 잘 쓰셨네요. ㄷㄷㄷ 후기 쓴 것만 봐도 뭔가 얻는 느낌이 들 정도입니다. 되게 하고 완성하고 최적화 하는 건 데블스에서 들었던 신경 쓸 일을 최소한으로 줄이라는 것과 약간 닮은 것 같습니다. 시작부터 최적의 코드를 짜려고 하는 것은 한 번에 너무 큰 일을 하려는 것 같네요. 평소에 그렇게 연습을 해 두면 나중에는 처음부터 조금 더 나은 코드를 짤 수 있겠지요. - 서민관
3.4. 서지혜 ¶
- '방한기념번개모임'이라고 할걸 그랬나
- 쓰다가 날아가서 의욕이 떨어지는군..
- (들린) 단어 클라우드
- 패턴을 이용한 리팩토링
- big ball of mud
- facade, wrapper 패턴등을 이용해 지저분한 구현을 숨길 수 있다!
- facade, wrapper 패턴등을 이용해 지저분한 구현을 숨길 수 있다!
- 상아탑의 설계
- agile is good for refactoring, 애자일을 사용하면 설계도 리팩토링할 수 있다.
- selfish class
- throwaway code. 정말 한번만 쓰고 버린다. 다시는 돌아보지 말아야한다.
- merciless deadline
- 변화의 속도. 가장 느린건 platform <-> 가장 빠른건 data
- refactoring : deciplined technique
- Internal structure
- External behavior
- Internal structure
- TDD? TFD?
- Test Driven Develope
- Test First Develope
- 교조적인 TFD X
- 테스트는 구현한 기능이 의도한대로 동작한다는 것을 검증하는 방법임. 테스트를 통해 적절한 피드백을 받을 수 있다면 된다.
- Test Driven Develope
- 리팩토링 종류에 따라 테스트에 미치는 영향도
- RENAME METHOD : LOW
- CHANGE METHOD or STRATEGY : MEDIUM
- 상속관계 분리, 프로시저 디자인변경, 도메인 분리, 계층구조 추출 : HIGH
- RENAME METHOD : LOW
- 패턴을 이용한 리팩토링
