허니몬의 IT 이야기/프로그래머, '코드 엔지니어' 2012. 6. 28. 21:16

20120627 TDD 실천법과 도구 - 2년 뒤

장소 : 회현 부근 LG CNS 2층 대회의실 발표자 : 채수원님


  채수원님의 책 [테스트 주도 개발 TDD 실천법과 도구] 책이 출간된지 2년의 시간이 흘렀다. 이 책이 나오기전 뭣도 모르는 상태에서 베타리딩을 신청했다. 베타리딩을 할 때도 그렇게 열심히 했다는 생각은 들지 않는다. 당시에 빠져있던 지독한 무력감을 벗어나기가 참 어려웠다. 그래도 꾸역꾸역 베타리딩을 하면서 TDD에 대해서 눈을 뜨게 되었다. 

'빨강(실패, fail!!)'에서 '파랑(성공, Success!!)'으로 바뀌는 재미를 느낀거다.

테스트 주도 개발 TDD 실천법과 도구

저자
채수원 지음
출판사
한빛미디어 | 2010-06-16 출간
카테고리
컴퓨터/IT
책소개
효율적인 설계와 간결한 코드를 만드는 필수 TDD 기법『TDD ...
가격비교


출처 : 아웃사이더님 인스타그램 : http://instagram.com/p/MX7-gIsvxw/


아.. 난 몰라.. 

나도 모르겠다!!

  채수원님이 어떤 이야기를 해주실지 두근두근하는 마음으로 자리에 앉았다.


  • 푸뤼하게 진행하는 것!! Free style!!
  • think smart - Change the world.

2년 동안

국내외의 내노라하는 개발자들이 모였다.

  • How do you do?

    I'm fine, and you?

  • 2010년
    • 난 뭐했지?
      • 나 말 정말 못한다. ㅡ0-)!! 이래 가지고 어디가서 발표할 수 있겠어?
  • 2011년
    • 모바일 교보문고
      • XP - 스프린트
      • 스프링
      • 스프링 시큐리티
      • ibatis
      • 아무 생각없이 한 것 같다. 그래... 좀 더 집중해서 했어야했어.
    • 회사 솔루션
      • DDD
      • TDD
      • 난 삽질 중이야. ㅡ0-)!!
    • 애자일
      • TDD
      • 짝코딩
      • 기획, 디자인 파트
      • 기획, 디자인과 개발 파트가 한데 어우러진 팀
    • 코딩 해본 게 언제인가?
      • 시뮬레이션
    • 봄싹 스터디에서 만나게 되었다.
      • 취업 사기단
      • 애자일을 적용할 수 있는 가능성
      • 안드로이드 번역
    • TDD
      • 주요 기능에 대한 테스트 이외에는 테스트케이스를 줄어들 게 되고 있다.
      • 업무적으로 테스트 커버리지 맞추라는 강요에 흥미를 잃어가고 있다.
    • 사람들의 무관심
      • 애자일
      • XP 스프린트에 대한 이야기가 점점 잦아들고 있다.
    • 애자일, 스크럼과 XP
    • 2년 전과 지금
      • 지쳐서 도망갈 사람은 도망갔다.
      • 체력 싸움
    • HTML5 & JavaScript -> App publish(Sencha였던가?)
    • Embeded
      • 2년 사이
    • 애자일 코칭
      • TDD가 잘하는 것만으로는 불충분 하다.
      • TDD가 아닌 것들
      • 몰라서 못하는 것보다 알면서 못하는 것이 더 힘들다.
      • TDD를 어려워하는 사람들
      • 정상적으로 돌아가는 것들에 드는 비용을 줄여라.
    • 안영회
      • TDD로 개발하는 지, 개발 후 jUnit만 끼워넣는 건지…
      • 프로젝트에서 테스트 커버리지를 정해놓고, 그걸 맞추기 위해 노력하게 된다.
      • 작게 쓰고 모호한 것들은 TDD를 통해서 진행하는 것이 좋다.
    • 루비를 쓰는 개발자
      • 보릿고개를 살아가고 있는 개발자
      • 루비 하지 마세요. ㅎㅎ
      • Startup
    • NHN 황상철
      • Spec by example -> 요구사항에 맞춰서 테스트를 작성해내는 것?
      • 어려워요. ㅡ0-)~
    • 서버, 통신쪽 위주로 한점
      • 스쿱미디어 CTO
  • TDD로 개발을 한 적 있나요?
    • 팀 전체가 TDD로 개발을 한적 있나요?
    • 몇 명쯤 변화 시켰나요?
      • 누군가를 변화시킨 적이 있는가?
    • 뭘 배웠을까?
    • 한 달 만에 20년 산 포도주와 비슷한 맛의 포도주를 만드는 방법!
      • 한달에 4시간 일하기!!?
      • 독하게 하는 사람들 : 소믈리에
      • 들어봐~~
  • 왜 안될까??
    • TDD를 써야 하나?
    • TDD가 안되는 이유?
    • 개발이 잘 안되는 이유?
    • 프로젝트가 실패하는 이유?
    • 오바하지마! vs. 원래는 안되는 거야!
      • 불편해하거나
      • 지속적으로 하지 않거나
  • CBD 실패의 이유…
    • 쓸 일이 없다.
    • 함수 -> 객체 -> 컴포넌트 의 단계를 제대로 겪어오지 못했다.
    • 방법론 등이 실패하는 이유
      • 사람은 쉽게 바뀌지 않는다.
    • 기술이 받쳐주지 못하기 때문에
      • 과거에도 있었지만, 현재에 그 개념을 구현할 수 있는 기술이 지원하기 때문에 유행되기 시작한 것들이 있다. 실패하게된 이유 중 하나는 그 당시에 개념들을 지원한 기술이 없었기 때문이다.
      • 공격과 방어!! +_+)~
    • CBD의 개념이 다르다.
      • 장사꾼(밴더, Vendor)
    • 무엇을 하려고 했는지 초심을 잊고, ‘어떤 결과를 얻으려는 욕심’ 키워갔다.
      • ‘무조건 된다’ 라는 욕심
    • ’문제가 있다.’는 큰 문제는 아니다.
      • ‘한 사람이 그 문제를 고민하면 된다.’
    • 다르게 생각한다.
      • 실패를 했다는 이야기… 성공을 한 것은 뭘까?
      • 성공과 실패를 말하기는 쉽지 않다. 언뜻 보면 모두 실패 같다.
      • 다른 렌즈로 보고 있다.
      • “어차피 안된다.”
        • 혈당이 낮으면 의지력이 떨어진다.
    • 목표와 역량의 차이!!


출처 : 정용식님 페이스북 :http://www.facebook.com/photo.php?fbid=386681444723742&set=a.163284913730064.36566.100001456685573&type=1&theater


배운점

  • 기술이 없어서 못하는 경우는 없다.
    • 핑계다!
    • 하는 사람은 다 해! -> 기술이 없어서 못한다고 생각한다.
    • 밀린다.
  • 왜 실패할까?
    • 무지 : 문제가 뭔지 몰라
    • 무시 : 변화를 시도하지 않는다.
    • 무지속 : 시도를 지속하지 않는다.
    • 무개선 : 개선하지 않는다. -> 내 이야기 같어!!
  • 대상이 없으니 감동이 적다
    • TDD로 뭘 해결할 수 있나? 무엇을 할 수 있는가? 목표의식?
    • 신기함은 잠깐
    • 감동도 잠깐
      • 현실이 녹녹치 않아요.
  • 재미가 없다
    • 커버리지의 압박!!(테스트 커버리지 압박, 수치로 체크!!)
  • 고민
    • 개인 ‘어떻게 하면 개발을 잘할 수 있을까?’
    • 회사 ‘좋은 개발자를 만들기 위해서는 어떻게 할까?’
  • 걍 하지 말까…
  • TDD 잘하는 사람 : 관찰하기
    • 우선 채수원님
      • 좋아하는 데 열심히 하는데 못하면 심란하다.
    • 협력업체 직원
      • 해야하니까.
    • 잘 하는 것처럼 보이는 캐릭
      • 우리팀 1등 개발자!!
    • 다음과 같은 조건을 가진 사람
      • 경험의 소유자 : 장점의 기억(좋은 경험을 가지고 있는 사람)
      • Divide & Conquer : 분할과 정복!?
      • 협력
    • 묻지 말게하고 시키자!!
      • 설계 먼저 하기
      • Given/When/Then : 기억을 남긴다. 자신이 테스트하려고 했던 것의 느낌…
      • Pen/Paper로 미리미리 그려보기
    • TDD 해보려면
      • 계획을 세우고, 연습을 하고, 피드백을 준다.
        • 기능 요구사항이 명확한지 확인
        • 머리속으로 단게를 그리고
        • 종이에 적어보기
        • 단계별로 확인해야할 경우 보기
    • 가장 중요하면서도 괴로운 질문
      • 시나리오를 써내려가서 문맥을 유지해라.
      • 지금 작성하려고 하는 코드에서 테스트를 작성할 수 있는 가장 간단한 것은?
        • 끊임없이 묻고 답하라.
      • LUHN 공식
        • 한국말인데 모르겠어.
        • Given : 16자리의 숫자가 나타난다.
        • When : - 우측숫자부터 2번째 숫자마다 2를 곱하고? - 1번째 숫자는 합쳐?
        • Then : 보안숫자와 일치해야한다 : 내 카드 번호 945가 나와야 한다.
    • 누가 좀 도와줬으면 좋겠어~ Some body help!!
      • 코드 리뷰 하자!! 라고 하면…
    • Mock Object
      • 개발자들은 Mock에 매우 흥미를 느낀다.
      • 하지만 불필요하게 만들어지는 코드가 많다.
      • 안쓰는 경우가 더 좋다.
    • 짝코딩!!
      • 짝으로 시키니 훨씬 낫다!!
      • 성공조건!!
        • 둘이 함께 같은 업무를 개발하는 것이다? -> 나는 O!!
        • 재미있으면 되지!! 둘이 같이 일하는 것을 편안하게 즐겁게 생각하면 되지 않을까나?
        • 가치관의 차이를 좁혀가는 것?
        • 가치관이 달라도 괜찮아. - 서로 다름을 이해하는거야. 소셜스킬(살이 닿고 호흡이 섞이고 코드가 섞이고… 응?) - 갈등해소 능력!!
        • 페어 프로그래밍을 할 때 중요한 상황은 화면보다 사람 사이에서 발생한다.
        • VIsion Planning : 함께 달성하고자하는 목표를 함께 얻는 것을 목표로 한다.
        • 요령과 발생할 수 있는 문제점, 그리고 대처 방식을 사전에 알려주어야 함
        • 드라이버와 네비게이터의 역할을 분명하게 할 것
      • 효율 높았던 경우
        • 프로젝트 초반
        • 서로 낯설었던 경우?
      • Do
        • 상대방에 대한 존중
        • 개발 업무의 목표를 잊지 않을 것
      • Don’t
        • 짜증
        • 100분 토론
        • Don’t에는 Do를 붙여라!
      • 짝코딩 실패 케이스
        • 자존심 대결
        • 마이크로 컨트롤 : 세세한 컨트롤, 지시를 내리고 기다리는 것에 미숙함
        • 너무 쉽거나 너무 어렵거나
        • 모르쇠로 일관하게 되는 경우?
      • 이건 뭐지!
        • 하면 좋긴 한데 힘들다.
        • TDD 안해도 된다.
        • 단위 테스트를 잘 만들면 좋다.
      • 외쿡!
        • 외국 소스들은 안그렇던데?
        • 없으면 defect report도 의심함
        • 기능추가 해도 테스트 코드 없으면 pull 안 받아줌.

정리

  • 기법/테크닉 별로 도움 안됨
  • 습관만이 살길
  • 느끼지 못하면 지속되지 않는다.
    • 재미를 느끼고 본인이 지속적으로 하지 않으면 변하지 않는다.
  • 사례와 상황들
    • 신입은 참 잘한다.
    • 정말 잘한다.
    • 기존 사원은 습관이 무섭다고 잘 안된다.
    • 머리 좋은 사람들도 경계해야 함
    • 함께 연습하면서 하는 것이 짱!
    • 버전업 때 변경사항을 수정하기 편리하다.
    • 문제는 대부분 테스트코드를 작성하지 않은 부분에서 생긴다.
    • 남코드 고치기에도 좋음
  • 업계 선배들의 책임
    • 본인 살기도 힘든 건 알지만 후배들도 챙기자
    • 후배가 없으면 동기 좀 챙기자
    • 선배랑도 잘 지내며 선배도 챙기자

회고

개인 의견

  • 김창준님 처음 뵙니다! ㅡ0-)~?
  • 채수원님의 책을 읽고 어디가서든 "TDD 합니다."라고 이야기 하지만, 실제로 TDD로 개발하는 경험은 그리 많지 않았다. TDD로 개발하기 보다는, 먼저 기능을 구현하기 거기에 짜맞추든 단위테스트를 진행하는 '착한 테스트'를 더 많이 하는 그런 개발자였다.
  • 개발자들 사이에서 애자일, 스크럼, XP 등의 이야기가 잦아들기 시작하는 이유는 뭘까?
  • 새로운 방법론과 개발론을 적용할 때 '왜 해야하는지'에 집중하기 보다 그것을 통해 '무엇을 얻을지'에 관심을 기울이고 있기 때문에 널리 퍼지지 않는 것은 아닐까?
  • 좋은 것이 있다는 것은 알지만, 쉽게 전파하기 어렵다.
  • 수원님이 TDD를 하시면서 전달하고 싶으신 내용이 많으셨던 것 같다. ^^;
  • 다른 사람들도 TDD 등에 대한 이야기를 서로 나누고 싶어하는 눈치였다. 조만간 이런 자리가 다시한번 마련되지 않을까하는 기대가 된다.
  • 말을 물가로 끌고 가기는 쉽다. 그러나 말에게 물을 먹이기는 어렵다. // 강제로 TDD를 시킬 수는 있다. 그러나 스스로 TDD를 즐기면서 개발하기란 쉽지 않은 법이다.



저작자표시

'허니몬의 IT 이야기 > 프로그래머, '코드 엔지니어'' 카테고리의 다른 글

멋쟁이 작은별 (동화구연 앱 제작) 프로젝트 도전!  (0) 2012.07.29
Python을 공부해볼 떄가 온 것 같다.  (0) 2012.07.27
20120623 공감세미나 8회  (3) 2012.06.23
20120519 KSUG 세미나 Part1. 참가 후기  (4) 2012.05.20
TDD의 생활화가 필요해.  (0) 2012.04.06