E D R , A S I H C RSS

Joseph Yoder방한번개모임


1. 소개


제4회 한국 SW 아키�트 대회�서 기조연설� 위해 방한한 Joseph Yoder가 한국 XP 모임(http://xper.org )� 여러분들� 위해 준비한 �리입니다. 리팩토�, 테스팅, 패턴 등� 주제로 간단하게 �야기하고 토론� 할 예정입니다. 특히 패턴쪽� 경험� 많으신 분�시�, 패턴 저작, 패턴 운�� 문화 등� 대해서� �야기를 해주시기로 했습니다. 장소대여비(토즈)를 위해 1�당 약 1~1.5만� 내외� 회비를 현장납부하셔야 합니다. 좀 � 아담하고 편안한 �리를 위해 20� �하� 소수만 선착순으로 받습니다. 강연(�어)� 대한 통역� 제공�지 않고, 토론/질답 시간�는 순차 통역� 제공�니다.


2. 프로그램

  • 세미나 ë‚´ìš©ì�„ 정리해 주세요
  • 질문ë�„ 정리해 주면 좋겠네요
  • 세미나 관련 ìž�료

3. 후기


3.1. 김수경

  • Worse is betterë�¼ëŠ” ë§�ì�´ ì�¸ìƒ�깊었다.
  • 너무 당연하게 TestDrivenDevelopmentë�¼ë©´ 테스트부터 작성해야한다고 ìƒ�ê°�하고있었는ë�° TDDê°€ 반드시 TestFirstDevelopmentì�¼ í•„ìš” 없다는 ë§�ì�„ 듣고 머리를 얻어맞ì�€ 것 같았다. 테스트를 언제 작성하는지가 중요한 게 아니ë�¼ 테스트를 통해 빠르게 피드백ì�„ 얻는 것ì�´ 중요.
  • Floss Refactoring. 다ì�Œì—� 리팩토ë§�해야지, 언제 ë‚  잡고 리팩토ë§�해야지가 아닌 í•­ìƒ� ê·¸ 때 í•  수 있는 리팩토ë§�ì�„ 하ìž�.
  • Namingì�´ 중요하다.
  • 질문ì�„ ë�” 효과ì �으로 하는 법ì�„ ì�µížˆìž�.
후기는 차차 � 다듬어서 쓰겠습니다.

3.2. 김준�

Joseph Yoder와� 만남. 신선했다면 신선했다�까. �렇게 빠른 외국�� 아키��설명� 들어본�� 없다. Pattern� 강� GoF와 같� 시초를 같� 했으며 �료 분야 소프트웨어 제작� 참여하고있다고 했다.

프로그램� �기소개, 리펙토�� 중요성, 기본�� 리펙토� 기법, Agile과 리펙토�� �관 관계, QnA, QnA중 Joseph� 쓰는 기법� 관한 설명 으로 �루어졌다.

처�� �러운 코드를 뜻하는 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

adaptiveobjectmodel� Joseph� 연구하고 있는 분야로 Refactoring� �황� 맞는 방법과 패턴� 쓰임세를 지정하는 모��다. 현재 쓰�는 패턴� 모�화해서 정리해서 했다고한다. 책�서나 보�것� 좀� 정확하고 명확하게 근거있게 설명하는것 같았다. 그리고 Refactoring� 필요한 �유� 대해서는 실제로 �렇게 하면 성공� 하기 때문� 리펙토�� 하는것� 좋다고했는� �것� 다른것� 비해 약한 근거�고했는� 그 �유는 리펙토�� 안한 �러운 코드� 성공� 하기 때문��고 했다. 하지만 �신있게 �하�면 리펙토�� 하는것� 좋다고했다.

변화 -> 추�화 �고 리펙토�� 잘못�� 경우 그 결과를 뒤집기는 좀 힘들다고했다. 패턴� 알면 장�� 많단다. 초보�가 패턴� 아는척 하면 다친단다. 테스팅과 패턴� 초보�가 하면 좋다. Refactoring� 좀� 잘할려면 첫 걸�� Rename부터.. 엄청난 프로그래머는 만드는것� 패턴으로 만들어질 수 있지만 대부분 그렇지 않다고 한다. 그러므로 리펙토�� 통해 수준� 높�는 훈련� 해놓는것� 좋다고한다. 그렇게 하면 ��하지 않아� �단다.

여러모로 Refactoring�서 나오는 Pattern과 Holub� 주장하는 Design Pattern과는 많았고 옆�서 계� 번역해주시는 창준선배님� 보면서 참 나� �어 듣기가 녹슬었구나 하는 ��� 들었다. FPS�서 �어를 배워�야하나. 여러사람� 다양하게 ��하는 Refactoring과 Pattern� 대해 다시한번 좀� 연구할 ���드는 시간�었다.
  • 후기 ì •ë§� 잘 쓰셨네요. ã„·ã„·ã„· 후기 ì“´ 것만 ë´�ë�„ 뭔가 얻는 ëŠ�낌ì�´ 들 ì •ë�„입니다. ë�˜ê²Œ 하고 완성하고 최ì �í™” 하는 ê±´ ë�°ë¸”스ì—�서 들었ë�˜ ì‹ ê²½ 쓸 ì�¼ì�„ 최소한으로 줄ì�´ë�¼ëŠ” 것과 약간 ë‹®ì�€ 것 같습니다. 시작부터 최ì �ì�˜ 코드를 짜려고 하는 것ì�€ 한 번ì—� 너무 í�° ì�¼ì�„ 하려는 것 같네요. í�‰ì†Œì—� 그렇게 연습ì�„ í•´ ë‘�ë©´ 나중ì—�는 처ì�Œë¶€í„° 조금 ë�” 나ì�€ 코드를 짤 수 있겠지요. - 서민관

3.3. 변형진


3.4. 서지혜

  • '방한기ë…�번개모임'ì�´ë�¼ê³  할걸 그랬나
  • 쓰다가 날아가서 ì�˜ìš•ì�´ 떨어지는군..
  • (들린) 단어 í�´ë�¼ìš°ë“œ
    • 패턴ì�„ ì�´ìš©í•œ 리팩토ë§�
    • 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. RENAME METHOD : LOW
      2. CHANGE METHOD or STRATEGY : MEDIUM
      3. ìƒ�ì†�관계 분리, 프로시저 ë””ìž�ì�¸ë³€ê²½, ë�„ë©”ì�¸ 분리, 계층구조 ì¶”ìœ : HIGH

3.5. 임�현

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
last modified 2021-02-07 05:23:36
Processing time 0.0083 sec