요 며칠전 일본 Twitter에서 인기를 끌었던 TDD에 대한 글을 번역해 봅니다. 일종의 조크이니 심각하게 바라보진 말아주세요. :p
감사주도개발 TDD (Thanks Driven Development)
TDD란 무엇인가?
감사(感謝, 고마움 표시)를 통해서 소프트웨어의 품질, 신뢰성, 고객만족도향상을 목표로 하는 프로그래밍 개발기법입니다.
TDD의 유용성
"감사따위로 품질이 높아진다는거냐?" 라고 생각하시는 분들은, 감사의 파워를 이해하지 못하는 사람들입니다. 감사는 사회인뿐 아니라, 어린이도 나이있으신 분들도 살아가는 프로세스의 일부로서 당연히 사용되고 있습니다. 그것을 개발기법으로 사용한 TDD의 유용성에 대해 이야기 하고 싶습니다.
프로젝트 시작
최초에 작성하는 것은 클래스의 정의도 테스트도 아닌 감사입니다.
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
printf("Thank you!!\n");
return EXIT_SUCCESS;
}
puts 'Thank you'
'이제부터 저는 코딩을 시작합니다. 개발환경을 주셔서 감사합니다.'라고 하는 기분을, 코드뿐 아니라 개발환경에도 전달하는 것으로 이후 프로젝트 진행에 좋은 영향을 줍니다.
예)
- 최초의 감사코드가 없었다면, 이클립스에서 '경고 없음'이 설정되어 있는 것을 몰랐을 것이다. 고마워!
- 컴파일러옵션으로 -Wall(모든경고표시 켜기) 이 붙어있지 않은 것을 못보고 지나쳤을뻔 했다.
변수명규칙
쓰고 버리는 임시 변수로 유명한 것은 'i,j,k'입니다.
TDD에서는 임시변수에도 감사하는 마음을 담지 않으면 안됩니다.
int h;
int a;
int n;
int k;
int s;
기존의 기법에서는, i, j, k의 3종류였던 것에 비해 감사의 마음을 잊지 않는다면, 무려 6종류까지 사용 가능합니다.
예)
- 감사를 잊지 않은 덕분에, 6중 for문 작성이 가능해 졌다! 고마워!!
코멘트 규칙
어떻게 하더라도 코드가 난해하게 기술될 수 밖에 없는 경우(정규식이나 메타프로그래밍 부분)에는 감사의 뜻을 적을 필요가 있습니다.
/**
* 잘 작동해줘서 고맙습니다.
*/
비슷한 기법으로 유명한 스피릿츄얼 엔지니어링 1에서는 아래와 같이 기술하고 있습니다.
스피릿츄얼엔지니어링의 기본은'기도'입니다.
'제발 동작해!'라고 하는 기도의 강함에 의해 좋은 코드를 만들어냅니다.
스피릿츄얼엔지니어링의 디펙토 표준인 코멘트에의해 아래와 같이 프로그램이 끝납니다.
// 부디 잘 되기를 기원합니다.
이 코멘트가, 코드 작동의 원동력이 된다는 것은 사실 말할필요도 없습니다만, 끊임없는 변화해 가는 상황에서 이런식의 '보수'적인 관점으로만 접근한건 좋지 않습니다. 왜냐하면, 이 기원이 정말로 효과를 발휘할까? 라고 하는 의문이 남기때문입니다. 기원의 강도가 생각했던 것 만큼에 다다르지 못한 경우라던가, 불안전하게 작동하게 될 가능성이 남아있습니다.// 기원이 효과가 있어서 감사합니다!
이렇게 함으로써, "이 코드는 실제로 동자하고 있다'고 말할 수 있는 동작실적을 얻을 수 있습니다.
"제발 동작해!'와 같은 기원에 '확실히 동작한다'와 같은 사후보고를 추가하는 것으로, 보다 유지보수성,신뢰성이 높은 코드를 구축해 가는 것이 가능합니다.
예)
- "잘 되길 기원합니다"같은 식의 뭐가 뭔지 잘 모르겠던 코드도, "고마워"라고 하는 코멘트를 보고, 확실히 작동하는 함수였다는 것을 알았다.
- 리팩터링 대상을 찾는 지표로서, 감사코멘트가 도움이 되었다!
도그푸드(Dog Food)
제품을 출하하기 전에, 시험운용으로서 사내의 사람들에게 사용해보게 하는 것으로 버그 발견이라던가, 유저빌리티 확보를 노리는 걸 "도그푸드(개밥)을 먹는다"라고 합니다.
같은 회사의 사람들이기 때문에, 어떻게해도 가볍게 응답합니다.
- XX가 작동 안해
- 이부분은 모양이 별로
- 사용하기 불편해
- 바쁜데 느리게 작동하잖아!
이 경우, '우리들이 만든 것을 이렇게 비난하다니'라던가
'말 안해도 알고 있다고!'와 같은 말을 종종 하곤 합니다.
감사주도개발에서는 그런건 터부시 합니다. 그렇습니다. 여기에서도 감사를 하는 것이 중요합니다.
XX가 작동하지 않아 => 버그인가.. 발생지점을 알려줘서 정말 감사합니다!
이 부분은 모양이 별로 => 디자인을 가르쳐줘서 정말 감사합니다!
사용하기 불편해 => 끝까지 사용해보는 경우도 생각하지 않으면 안돼! 초심을 잃었어. 감사합니다.
느리다구! => 튜닝할 우선순위를 결정할수 있었다. 감사합니다.
유저의 악평도, 시점을 바꾸면 개선의 지름길인 것이다.
릴리즈 후
사내 검증도 끝났고, 무사납품이 가능해졌습니다.
이후는 유지보수 작업입니다. 여행을 떠난 프로그램과 대면해야 하는 시점이 다시 찾아옵니다.
이때, 앞에서 적은 다양한 감사가, 유지보수 작업자와 디버깅 작업자들의 마음을 받쳐주는 기둥이 됩니다.
예)
- 감사가 많은 부분을 참고로해서 점점 확장시켜 나자자!
- 여기에 '감사'가 많다는 것은, 그 만큼 억세스한 사람도 많다는 뜻. 결국 이 부분의 퍼포먼스를 올리면 점점 좋아질거다!
마지막으로
감사주도라 것은 개발기법으로서가 아니라, 확실히 살아가는 방법이라고 말할 수 있습니다.
무언가 조금이라도 자신에게 있어 플러스가 될 수 있다면,
혹은 플러스가 될 것 같은 예감이 든다면
감사를 잊지 않음으로써, 언젠가는 높은 위치에 다다를 수 있습니다.
그리고, 어느 사이엔가 자신이 감사받는 입장이 되는겁니다.그대여, 부디 감사를 잊는 법이 없기를!。
Special Thanks
- Legacy Hacks (p.36 eXtreme HAGO LT 大会 2011 Winterより)
http://tomohiro.me/slide/2011_xhago_winter/legacy_hacks.pdf
- Twitter / @Naoto SHINGAKI: 감사주도개발에서는 변수명에도 신경써주면좋겠어. i,j,k가 아니라 t,h,a,n,k로 정의하자구.
- 스피릿츄얼 엔지니어링은 프로그래밍을 크게 정신세계와 물질세계로 나눈다. 스피릿츄얼 엔지니어링의 기초는 다음과 같다. '제발 작동해줘!', '절대 장애나 사고따윈 없어야 해!', '나.. 이번 릴리즈만 잘 끝나면 결혼한다구' 등의 정신세계가 물질계(네트워크, 서버, 프로그램)등에 영향을 미친다는 걸 이해해야 한다. 특히 의욕이나 집중력, 이익여부, 운빨이 더해져 물질계가 변화된다는 사상이다. [본문으로]
'이생각 저생각' 카테고리의 다른 글
| P-Camp & 대안언어축제 2011 참가후기 (4) | 2011.03.16 |
|---|---|
| Git vs Mercurial (기트 대 머큐리얼.. 으응?) (10) | 2011.03.09 |
| 나의 멘토는 어디에 있는가? (Where is my mentor?) (14) | 2011.01.20 |
| 2011년 새해인사 (0) | 2011.01.04 |
| [dw Review] 구글토크 호환 메신저를 만들고 싶다면? XMPP! (2) | 2010.11.30 |
