블로그 이미지
소프트웨어 개발 경험을 공유하고 싶은 재밌게 사는 소프트웨어 엔지니어입니다^^

카테고리

Chungha Story (45)
Agile Experience (22)
My Family (4)
Life Style (8)
Programming (8)
Android (2)
Total164,391
Today14
Yesterday11

James Grenning의 TDD and Refactoring Workshop 참가

 

몇주전 사내 역량강화센터 분들의 도움으로 매우 귀한 교육에 참가하였습니다.

TDD에 대해서는 오래전 부터 관심을 갖고 실무에 적용해보려 하였지만, 지속적으로 유지하지는 못했었습니다.ㅠㅠ

이번에 하던 업무가 정리되던 타이밍에 맞춰서 좋은 교육이 소개 되어 바로 참석하였는데, 이것은 실로 엄청난 경험이었습니다!!

사실 제가 영어 실력이 많이 딸려서, 한마디 한마디 모두 새기진 못했지만, 우리에게는 정말 잘 통하는 언어가 있었습니다. 그가 준비한 코드들과 시연하면서 보여준 코딩 모습들은 모두 저에게 큰 인사이트를 보여주었습니다.

 

 

 

그가 발표한 내용 중 가장 흥미로운 그림은 위의 그림과 같이 무수히 많은 공으로 저글링을 하는 것이었습니다.

현재 우리는 많은 공으로 저글링 하는 것처럼 많은 문제를 모두 다 노출시킨뒤에 해결하고 있다는 것입니다.

저도 그렇게 하고 있었겠지만, 생각만해도 끔찍합니다.ㅠㅠ

TDD는 한번에 하나의 문제만 해결하는데 집중하도록 하고 있습니다.

 

Uncle Bob's Three Rules of TDD

1. Write no production code, except to pass a failing test

2. Write only enough of a test to demonstrate a failure

3. Write only enough production code to pass a test

 

궁금 했던 것들에 대한 해답을 찾다.


제가 궁금했던 부분은 세가지 정도 였습니다.

첫번째는 테스트 코드에 대한 관리 이슈입니다. 프로젝트가 성장하다보면 테스트 코드의 비중도 높아지게 됩니다.

프로덕트 코드가 리팩토링 되면 테스트 코드에도 영향을 줄 수 있습니다. 테스트 코드의 원저작자가 없다면 문제가 될 수도 있습니다. 특히나 요즘처럼 자신의 코드가 아니면 Owner-ship을 전혀 가지지 않는 개발 문화에서는 더욱 문제가 됩니다.

James는 항상 테스트 코드를 깨끗하게 유지하라고 하였습니다. 리팩토링의 대상이 프로덕트 코드만이 아닌 테스트 코드도 포함된다고 하였습니다. 그리고 중요한것 중에 하나는 테스트 코드를 너무 많이 만들면 안되는 것입니다.

Unit Test 30개 + Integration Test 10개로 되는 것을 Integration Test로만 Cover하려다 보면 테스트 코드는 수백개가 넘어도 모자를 것입니다. TDD를 하다보면 자연 스럽게 Unit Test와 Integration Test의 조합을 구성하게 되며, 따라서 적은 테스트로도 높은 Test Coverage를 만들어 낼수 있습니다.


두번째는 TDD를 소개하다보면 "오버헤드가 크다, 작업이 너무 느려진다"라는 질문을 많이 받는데, 그때마다 정확히 설득하지 못했었습니다. 이는 기존의 개발 방법 대비 작업이 느려지게 느끼는 것일 뿐입니다 라고 James는 말하였습니다. Debugging이란 작업은 매우 Unpredictable 한데 비해 개발자는 Debugging 이전에 개발 완료라고 느끼는 경우가 많다는 것이죠. 아래 그림 처럼 Debugging 이전까지는 기존 개발 방법이 빠르게 느껴지지만, 코드가 버그 없이 완성되는 것은 TDD가 빠릅니다.



 

세번째는 TDD Step의 크기가 궁금했습니다. 책에서처럼 너무 작은 단위로 하다보면 살짝 멍청해보였습니다. TDD의 적용 방법은 어떤 작업이냐 혹은 작업자가 그 작업에 대한 경험이 얼마나 있는가에 따라서 달라질 수 있습니다. TDD에서 말하는 Small Step은 어떤 상황에서도 TDD를 적용할 수 있게 하는 기본적인 스킬 입니다. 처음에는 Small Step으로 계속 연습하는 것이 좋을 것 같습니다. 익숙해 진다면 Step의 크기를 자유자재로 조절할 수 있다고 합니다.


결국 제가 깨달은것은, "나는 TDD에 대해서 진정 아는 것이 없었구나!" 라는 것이었습니다.

매우 슬펐지만 반대로 무척 기뻤습니다.^^


James의 Workshop을 따라해보면 나도 우리 동료과 TDD를 할수 있지 않을까?


James는 Dojo 시스템을 이용하여 본인이 준비한 코드들과 인스트럭션으로 Group Activity를 진행하도록 하였습니다.

또한 Group Activity는 랜덤하게 2인 단위로 Pair Programming을 유도하였습니다.

Workshop참가자들이 대부분 애자일 개발에 이미 익숙한 사람이 많았고 적극적인 사람들이었기 때문 일수도 있지만, 참가자들 대부분이 매우 몰입해서 Workshop에 임하였다는 것이 매우 흥미로웠습니다.


그래서 따라해보기로 했습니다. 무작정 팀내 공지를 하였고 (약 50여명) 무작정 대회의실을 잡고, 무작정 날짜를 잡았습니다. 회비도 유례없이 미리 선불로 받았습니다. (2만원 - 뒷풀이 비용)

팀내 워크샵 당일까지 약 16명이 등록을 하였고, 모두 참석하여 약 2시간 동안 진행하였습니다. 참가자들의 직위는 책임연구원부터 연구원까지 다양하였습니다. 

 

James가 했던 내용, Group Activity를 그대로 진행하였습니다.

제가 기억 나는데로~ 물론 애드립이 난무하긴 했지만, 초반에 시작할때 성공적인 S/W에 대해서 공유도 하고, 본인이 개발시에 좋아하는 것과 싫어하는 것도 공유하였습니다.

대부분 디버깅과 테스트를 싫어하시더라구요...ㅎㅎㅎ 디버깅은 우리의 적이죠..

제가 30분 정도 TDD로 Circular Queue를 만드는 과정을 데모로 보여드리고, 랜덤하게 2명씩 짝 지어서 30분간 Pair Programming으로 TDD로 Circular Queue를 끝까지 만들어 보도록 하였습니다.

Small Step과 한번에 하나의 테스트 케이스를 계속 강조했습니다.

아래 사진에 맨 앞에 두분이 책임 말년인데 정말 열심히하시더라구요~ 워크샵 끝나고도 자발적으로 며칠 더 진행하셨습니다. Thread-Safe 까지 검증하는 테스트 케이스를 만드셨더라구요..ㅎㅎ 대박..

 

 


어라 이거 효과가 있네요?^^ (회고)

 

매우 간소하게 James 따라하기 워크샵을 진행하고 나서, 간단하게 회고를 진행하였습니다.

질문은 두가지 였습니다.

TDD에 대한 긍정적인 느낌

TDD를 업무에 적용한다고 상상했을때 가장 먼저 떠오르는 걱정


 

먼저 TDD에 대한 긍정적인 느낌에 대해서는 아래와 같이 답해주셨습니다. (작성한 그대로 옮겼습니다.)

생각보다 재미있고 긍정적인 회고 내용이 많았습니다. 제가 말로만 설득할때와는 전혀 다른 반응입니다!

특히 Pair Programming에 대한 긍정적인 느낌은 매우 인상적이었습니다^^

 

- 새로운 개발 방법을 알게 되어서 좋았음. 비록 처음 익히기는 어렵겠지만 익숙해지만 Error를 사전에 예방할 수 있어서 개발시에 많은 도움이 될 것 같음

- Pair Programming 해보니 상대방이 나와 다르게 생각하는 부분을 알게된다. 처음부터 복잡하게 이것저것 다 생각하지 않고, 하나하나 순서대로 해서 좋다.

- 구멍이 없는 프로그램을 만들 수 있을 것 같다. 프로그래밍 개발시에 다른 함수를 추가하면서 기존 함수를 - 고칠 때 기존 함수에 대한 Test가 누적되어서 테스트가 보장됨.

- 쉽게 따라 할 수 있어서 좋았습니다.

- 잠들어가는 나의 뇌를 깨울수 있는 흥미있는 Programming 접근방법

- 반복적인 테스트 Set을 구축/확장하기 용이하다

- Code를 꼼꼼히 생각하며 짤수 있다.

- Test Case 자체가 Application이기 때문에 Caller 입장에서 구현할 수 있음.

- 재밌다(신기) ㅋㅋ 한번 업무에 활용해보고 싶다.

- 코딩이랑 테스트랑 같이하니 시간 절약은 될듯. 그러나 테스트가 명확해야 함.

- 잘하면 좋은 방법론이 될 듯하다.

- 계속해서 코딩단계부터 예외사항을 고려하게 된다.

 

두번째는 TDD를 업무에 적용한다고 상상했을때 가장 먼저 떠오르는 걱정입니다.

역시 업무 속도가 느려질것 같다는 걱정이 많습니다. 위에서 설명한 것처럼 실제로는 느리지 않다는게 핵심이죠

레거시 코드에 대해서 걱정하시는 분도 있습니다. 레거시 코드는 저도 무지 걱정됩니다.^^; 따로 다루어야 할 내용입니다.

 

- 내가 만드는 Test case에 hole이 분명! 있을거다. TDD하고도 이모양이냐는 비난?

- Project 파일에 junit을 어떻게 추가하는지? 코드의 규모가 커졌을 때는?

- 개발 시간이 많이 걸리고 알고리즘이 핵심인 SW에는 적용이 제한적일 것 같음. Step이 커질때 실수 할 수 있지 않을까?

- TDD에 익숙해지기 까지 업무속도가 느려질 것 같다. TDD를 이해하는 협업하는 분위기가 아니라면 좀 힘들듯...

- 코딩 및 설계과정에서 테스트 내용을 명확히 짚고 가야 할 거 같음

- 처음 하는 것이라 시간이 많이 걸릴것 같다. 보통 처음 설계부터 하는 개발이 아는 경우 어떻게 적용?

- 초반에 시간이 많이 걸림. 확실한 test case를 만드는데 어려움 있을듯

- 어느 단위 (어느 레벨)에서부터 적용할지 의문이 생김

- 일정이 촉박하면 이런거 다 무시하고 닥치는 데로 코딩하는 마음이 생길 수 있다.

- 개발 속도가 느리다.

- TDD를 익힐 때까지 기존의 습관을 고쳐야 할 것 같음. Test case를 정하기가 어려움.

- 아직 익숙치가 않아서 그럴지 모르지만 시간이 많이 걸릴것 같다. 내가 뽑은 테스트 케이스 외에 여러가지 다른 케이스가 있을 것 같다. 시간에 쫒겨 개발시에 이걸 적용할 수 있을지

 

생각보다 반응이 너무 좋아서 2부를 진행해보려고 합니다.

2부에는 Test 하기 좋은 클래스 설계하기 및 Mock Object 사용해보기로 진행해보려구요

또한 이러한 워크샵 형태로 스터디를 진행할 예정입니다. 그리고 내년에 제가 참가하는 프로젝트에서는 TDD를 매우 적극적으로 장려하고 적용할 생각입니다. 물론 현재 프로젝트에도 개인적으로 적용을 해봤구요. 정말 흥미 진진한 2013년이 될것 같습니다.

 

James 덕분에 동료들이랑 정말 좋은 경험 하고 있네요!

James가 이 글을 보진 못하겠지만 정말 감사하다고 말씀드리고 싶어요..!^^

Posted by 윤청하

댓글을 달아 주세요

  1. 2012.12.21 06:55 신고 한주영  댓글주소  수정/삭제  댓글쓰기

    멋지네요. 2시간이라는 짧은 시간에 이런 훌륭한 워크샵을 진행하신 건 정말 대단해요. 두번째 워크샵은 서초 전체로 오픈하면 어떨까요. 저도 참석해서 학생이든 보조든 동참하고 싶어요. 사전 참가비 2만원 유지하고. ㅎㅎ 저도 예전에 파싱 세미나 개설하면서 사전에 참가비 입금을 받았는데 저희 교육팀장님이 딴지 거셔서 되돌려드린적이 있어요. 하지만 좋은 시도 같아요. 주요 내용을 번역해서 제임스에게 알려줘도 좋을 것 같아요.

    • 2012.12.21 07:34 신고 윤청하  댓글주소  수정/삭제

      댓글 주셔서 감사합니다.^^ 뒷풀이 비용으로 받는 2만원은 별거 아닐수 있지만 참여자의 관심도가 달라지는것 같아요..ㅎㅎ
      서초 전체 오픈은 좋은 생각입니다! 그런데 일단 소규모로 준비하고 검증을 해보고 진행해 보는 것이 어떨까 싶어요~ 팀내에서 진행하는건 1월 둘째주에 바로 진행해 보고 반응을 보려구요^^

  2. 2012.12.24 18:22 신고 김대석  댓글주소  수정/삭제  댓글쓰기

    오.. 오랜만의 글이네. 잘 지내지? TDD Workshop 재밌었겠다.

    • 2012.12.26 09:17 신고 윤청하  댓글주소  수정/삭제

      웅..ㅋㅋ 올만에 썼엉.. 이거 쓰는데도 일주일정도 걸린거 같앙..
      요즘 회사외의 시간중에 내시간이 거의 없당..ㅋㅋㅋ
      TDD 잼있엉.. 내년에는 꼭 실무에서의 Small Success를 만들어보려궁..^^

  3. 2012.12.26 15:37 신고 김대석  댓글주소  수정/삭제  댓글쓰기

    자식 있는 사람이 회사 외에 내 시간이 어딨어. 나도 애기 보느라 힘들당 ㅎㅎ
    우리 회사에서는 이제 겨우 단위 테스트랑 일일빌드 적용하는 걸음마 단계라 TDD는 좀 더 있다 봐야 할 듯 ㅎㅎ

    • 2012.12.26 16:26 신고 윤청하  댓글주소  수정/삭제

      단위테스트라는게 말그대로 Unit Test를 말하는거야? 아님 CppUnit, JUnit과 같은 Unit Test Framework을 쓴다는 것이야?
      보통 TDD를 안하고 Unit Test를 한다는 것을 보면 Unit Test Framework을 써서 Integration Test 이상을 하거든... 그냥 궁금해서^^

  4. 2013.01.02 15:55 신고 김대석  댓글주소  수정/삭제  댓글쓰기

    말 그대로 Unit Test를 하고 있어. TDD는 개발 방식까지 포괄하는 개념이라 적용하지 않고 Unit Test만 먼저 적용하고 있지.

  5. 2013.01.11 14:09 신고 지나가다가  댓글주소  수정/삭제  댓글쓰기

    xper 그룹 이메일 보고 들어왔습니다. 알차게 부럽네요~ 역시 뭐니뭐니해도 실천이죠! TDD 이야기보다 실무에 적용하는 이야기가 더 와 닿아 글 남깁니다. 개발 초년생 입니다. 올바른 개발 문화의 예를 앞으로도 많이 만나게 해주세요! 화이팅!

"이거 전에 잘 되던건데 왜 안되죠?"
개발자를 당혹케하는 질문중에 하나이다. 난 분명 관련 내용을 수정한 적이 없는데(다른 부분에 수정한건 있지만) 머지?
만약 높은 사람 앞에서 데모 중이었거나 출시를 코앞에 두고 위와 같은 질문이 들어온다면 아마 대부분 머리속이 하얘질 것이다.
도데체 어디서부터 어느 부분에서 문제가 된걸까?
우리는 버전 관리 시스템을 통해 구현 히스토리를 모두 검토해볼수 있다. 혹은 과거의 버전으로 돌릴수도 있다.
이제부터 꼬이기 시작한다. 그리고 계속 버전을 헤맨다.
분명 다른데서 문제의 원인을 발생시킨걸거야.. 내 문제가 아니라는 것을 증명해야되.. 피해갈 구멍만 찾는다.

문제가 발생했을때 가장 먼저 해야 할일은 문제를 정의하는 것이다.
이전에 잘 되었던것은 다른 문제다. 현재 안되는것이 문제이다. 문제를 잘못 정의 했을때 우리는 삽질을 한다.
자신이 삽질로 야근이나 밤샘 중에 있다면 다시한번 생각해보는 것이 좋다. 내가 고치고자 하는 문제가 정확히 무엇인지..

아직도 과거의 히스토리를 뒤질 차례는 아니다. 다음에 해야할일은 문제를 분석하는 것이다.
문제를 발생하는 원인에 대해서 정확히 파악해야 한다. 그 후에 히스토리를 참고 하던 내 문제가 아님을 증명하던 이실직고 하고 수정하건지 하면된다.
의외로 이런 과정을 천천히 제대로 진행하면 어떻게하면 빨리 이 상황을 벗어날까 조마조마 하면서 삽질하는 것보다 굉장히 빠르게 문제를 정확히 해결 할 수 있다.
그리고 아마 재발하지 않을 것이다. 재발 하더라도 본인 문제가 아닐 것이다.

소프트웨어 개발 생산성은 코딩 속도에서 오지 않는다.
회사도 마찬가지다. 중요한건 현재의 에티튜드..

Posted by 윤청하

댓글을 달아 주세요

  1. 2011.11.24 21:30 신고 뇨릉  댓글주소  수정/삭제  댓글쓰기

    저도 가끔 문제를 정확히 파악하는데 집중을 하지않고 어떻게든 다른 핑계를 찾는 개발자를 보곤합니다.
    그러면 삽질로 가는 지름길인데...

  2. 2012.06.14 16:50 신고 무대포개발자  댓글주소  수정/삭제  댓글쓰기

    좋은 자료입니다. 자료 퍼갈게요 ^^

프로젝트 초반, 그리고 설계

상위설계(High Level Design)는 일반적으로 프로젝트 초반에 작성됩니다. 상위설계는 해당 프로젝트의 결과물의 근간이 되기 때문에 매우 중요하며 크게 변하는 경우는 드뭅니다. 어디까지나 상위설계이기 때문이죠. 뜬구름 잡는 얘기일 수도 있기 때문에 기술적으로 아주 세세하게 알지 못해도 작성할수 있는 경우가 있습니다. 하지만 상세설계(Low Level Design)에 접어들게 되면 구체적으로 많은 선택을 해야합니다. 골치 아프죠.
많은 경우에 어느 수준까지 작성해야 할지 갈피를 못잡고 방황하다가 적당히 보고 수준의 문서를 작성하고 구현에 들어갑니다. 결국 구현 따로 상세설계 따로인 결과물이 탄생하게 됩니다.

유지보수와 스파게티 코드 양산

유지보수중 스파게티 코드를 양산하게 되는 경우중 하나는 소스코드만 가지고 문제 해결을 할수 밖에 없는 경우 입니다. 아마 대부분의 경우가 이러할꺼라 생각됩니다. 근본적으로 문제를 해결하고 싶지만 근본적인 원인을 찾는데 도움이 될수 있는 큰 그림을 볼 수 있는 단서가 유지보수 단계에까지 남아있는 경우가 드물죠. 결국 기존 소스를 분석하다 지쳐서 땜빵코드를 삽입할수 밖에 없는 경지에 이릅니다. 제가 아는 대부분의 개발자는 땜빵코드를 삽입하는 것에 대해 부정적이지만 어쩔수 없이 하는 경우가 많습니다. 물론 저를 포함해서..


파일럿 프로젝트로 시작하는 '동작하는' 프로젝트

앞에서도 말씀드렸지만 상세설계를 어느 수준까지 작성해야할지 고민되는 경우가 많습니다. 저는 이를 해결하기 위해 프로젝트 초반에 파일럿 프로젝트를 진행합니다. 어떤 레퍼런스를 쓰던 일단 원하는 결과물을 얻기 위해 이것 저것 시도해보며 최종적으로 해당 기능들을 간신히 수행하는(하지만 있을건 다있는) '동작하는' 소스코드를 만들어 냅니다. 그리고 이것을 통해 프로젝트를 본격적으로 시작할때부터 '동작하는' 소스코드를 가지고 시작할 수 있게 합니다. 그리고 현재 수준에서 껍데기(Front-End) 바로 아래부분(Top)부터 추상화(Abstraction)을 통한 인터페이스 추출(Interface Extraction) 작업을 시작합니다. 추출된 인터페이스를 정리하면 매우 간단한(Class가 몇개 안되는) Class Diagram과 Sequence Diagram을 그릴수 있습니다. 이것이 상세설계서의 0.01 버전이 될수 있겠습니다. 이를 바탕으로 리팩토링을 하게 되면 인터페이스 추출이 완료된 상위 클래스를 제외하고는 나머지는 뚱땡이 클래스가 되어있겠죠. 이제 시작입니다.

Top-Down으로 진행되는 리팩토링, 그리고 지속적인 설계

리팩토링을 Top-Down으로 하게 되면 소스코드의 리팩토링 단위가 커지게 되므로 보통은 추천하지 않습니다. 하지만 설계는 Top-Down으로 할수록 깔끔해집니다.(제 의견입니다.) 가장 상위(Top)부터 시작하여 단계적으로 하위(Bottom)까지 진행되는 인터페이스 추출은 리팩토링을 지속적으로 하도록 유도합니다. 그리고 리팩토링된 소스코드는 항상 '동작하는' 상태여야 합니다. 그리고 결과물인 소스코드와 UML 문서는 최소 1명의 팀원과 리뷰를 합니다. 반복하다보면 뚱땡이 클래스들이 점점 분리되여 계층적인 클래스 구조를 만들게 될겁니다. 고럼 다음과 같은 프로세스가 만들어 집니다.


주기는 짧을 수록 좋다

저는 위의 주기를 하루에 최소 한번 할수 있도록 개발 계획을 수립합니다. (작은 마일스톤으로 쪼개는 방법은 다음에 써보도록 하겠습니다.) 그나마 주기가 짧아야 리팩토링 단위와 정리해야할 UML 문서의 단위가 작아집니다.

결과적으로 얻을 수 있는건..
  1. 항상 '동작하는' 소스코드
  2. 항상 정확하게 현재 소스코드를 큰 그림으로 파악(Static and Dynamic!)할 수 있는 딸랑 2종류의 UML Diagram
  3. 새로운 기능 넣기 전에 UML Diagram 으로 검토하는 습관...
  4. 바쁜 이슈처리 상황에서 근본적으로 문제해결을 할 수 있는 여유..
  5. 객체지향적 설계 능력?ㅡㅡ;;
그런데 결국은 뭐라도 해봐야..뭐가 다른지 압니다.

Posted by 윤청하

댓글을 달아 주세요

  1. 2011.02.16 10:49 신고 k16wire  댓글주소  수정/삭제  댓글쓰기

    지속적인 설계라는 표현 맘에 드네요. ^^

  2. 2013.04.08 03:57 신고 longchamp  댓글주소  수정/삭제  댓글쓰기

    http://mih.freerunso.com/

티스토리 툴바