20120627 TDD 실천법과 도구 - 2년 뒤
장소 : 회현 부근 LG CNS 2층 대회의실 발표자 : 채수원님
채수원님의 책 [테스트 주도 개발 TDD 실천법과 도구] 책이 출간된지 2년의 시간이 흘렀다. 이 책이 나오기전 뭣도 모르는 상태에서 베타리딩을 신청했다. 베타리딩을 할 때도 그렇게 열심히 했다는 생각은 들지 않는다. 당시에 빠져있던 지독한 무력감을 벗어나기가 참 어려웠다. 그래도 꾸역꾸역 베타리딩을 하면서 TDD에 대해서 눈을 뜨게 되었다.
'빨강(실패, fail!!)'에서 '파랑(성공, Success!!)'으로 바뀌는 재미를 느낀거다.
아.. 난 몰라..
나도 모르겠다!!
채수원님이 어떤 이야기를 해주실지 두근두근하는 마음으로 자리에 앉았다.
- 푸뤼하게 진행하는 것!! 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 |
