neolith의 방
![[레벨:13]](http://old.lameproof.com/modules/point/icons/default/13.gif "포인트:16257point (43%), 레벨:13/30"){kind=icon}
채이아빠![[레벨:0]](http://old.lameproof.com/modules/point/icons/default/0.gif "포인트:0point (0%), 레벨:0/30"){kind=icon}
21프로그래밍에 있어서 TDD 의 등장이란, 회계의 역사에 있어서 '복식부기의 도입'과도 비슷한 의미를 갖는다.
물론 TDD 는 만병통치약이 아니다. 복식부기를 쓴다고 견실한 기업재무구조가 보장된다는 의미는 아닌 것처럼. 그저 기본적으로 해야 하는 것 뿐이다
물론 TDD 는 만병통치약이 아니다. 복식부기를 쓴다고 견실한 기업재무구조가 보장된다는 의미는 아닌 것처럼. 그저 기본적으로 해야 하는 것 뿐이다
imcgames 의 김학규입니다
2009.12.05 16:55:29 (*.162.71.243)
![[레벨:2]](http://old.lameproof.com/modules/point/icons/default/2.gif "포인트:676point (70%), 레벨:2/30"){kind=icon}
imays 엽기적 TDD case를 소개해주시면 사례 공부에 도움이 될거같아요.
저희의 엽기 TDD case: 공유기 홀펀칭이 잘 되는지 확인하기 위해 외국에서 공수한 희귀종 공유기 포함 28종 공유기들을 랜카드 30개에 물려서 매주 유닛테스트를 실행
저희의 엽기 TDD case: 공유기 홀펀칭이 잘 되는지 확인하기 위해 외국에서 공수한 희귀종 공유기 포함 28종 공유기들을 랜카드 30개에 물려서 매주 유닛테스트를 실행
2009.12.07 00:55:32 (*.33.110.135)
채이아빠 공유기들의 경우에는 극단적 테스트 케이스라고는 할 수 있지만, 극단적 TDD 랑은 거리가 있네요. 위의 사례가 TDD 라고 한다면 희귀한 공유기들을 랜카드에 물리다보니까 새로운 디자인 패턴을 발견했다던가 하는 얘기가 나와야 하지 않을까요?
2009.12.09 02:02:56 (*.50.13.30)
![[레벨:1]](http://old.lameproof.com/modules/point/icons/default/1.gif "포인트:334point (90%), 레벨:1/30"){kind=icon}
PizaNiko tdd말입니다만, 요근래의 개발 프로세스를 보다 보면, '기술이 뒷받침되어 새롭게 일어나는 프로세스가'가 정말 많은 것 같습니다.
tdd만해도 일일빌드나, 빌드 자동화 스크립트, 유닛테스트 스크립트, 자동화 테스트 같은 것들이 뒷팓침이 되지 않았다면 어떻게 됐을지 알 수 없으니까 말이죠.
tdd만해도 일일빌드나, 빌드 자동화 스크립트, 유닛테스트 스크립트, 자동화 테스트 같은 것들이 뒷팓침이 되지 않았다면 어떻게 됐을지 알 수 없으니까 말이죠.
2009.12.09 04:35:55 (*.33.110.135)
채이아빠 tdd 자체가 꼭 기술이 뒷받침 되어야 하진 않는다고 봅니다. 물론 tdd 를 적용한 상태를 한차원 더 끌어올릴 수는 있겠죠. 위에 언급하신 툴들의 목표는 상시통합(CI) 이고 CI 자체는 TDD 와는 또 다른 문제니까요
그냥 어떤 문제를 봤을 때, TDD 에 익숙해진 사람이라면 예외나 경계에 속하는 몇개의 테스트케이스를 금방 떠올리고 그것을 코드로 표현함으로써 생각의 진전을 원활하게 해주는 효과는 툴 하나도 없이도 충분합니다
위의 예를 제가 예로 들었던 '복식부기' 에 비유해보자면, 복식부기와 경영정보 시스템 (MIS)의 관계와도 유사하지 않나 하는 생각이 듭니다. 그러고보니 CI 가 추구하는 바랑 MIS 가 추구하는 바랑도 유사성이 크네요
얼마전에 읽은 회계학콘서트2 (만화로 되어있는 기업회계 입문서입니다. 추천할만한 책) 에 보면 조직의 각 부문 (영업, 제조, 연구 등) 과 회사내의 프로젝트들 (아동복, 숙녀복, 정장 등) 이 각각 조직의 이익과 손실에 어떻게
영향을 주는지 알아야 한다는 취지를 설명하고, 경영 대시보드 라는 개념을 통해서 현재 회계 상태를 점검하라는 조언이 나옵니다. 소프트웨어 개발도 마찬가지인데, 완성된 시스템에 영향을 끼치는 각각의 컴포넌트의 상태를
CI 툴에서 제공하는 대시보드 UI 를 통하여 요구조건을 충족하는 상태인지 아닌지를 항상 점검하라는 것이 CI 가 추구하는 목표중 하나죠. 대시보드라는 개념이나 그 원리나 비슷하군요. 어쩌면 CI 가 MIS 쪽에서 그 개념들을 배워왔기
때문일지도 모르겠습니다. TDD 나 Lean 개발도 공업에서 배워온 개념이니까요.
그냥 어떤 문제를 봤을 때, TDD 에 익숙해진 사람이라면 예외나 경계에 속하는 몇개의 테스트케이스를 금방 떠올리고 그것을 코드로 표현함으로써 생각의 진전을 원활하게 해주는 효과는 툴 하나도 없이도 충분합니다
위의 예를 제가 예로 들었던 '복식부기' 에 비유해보자면, 복식부기와 경영정보 시스템 (MIS)의 관계와도 유사하지 않나 하는 생각이 듭니다. 그러고보니 CI 가 추구하는 바랑 MIS 가 추구하는 바랑도 유사성이 크네요
얼마전에 읽은 회계학콘서트2 (만화로 되어있는 기업회계 입문서입니다. 추천할만한 책) 에 보면 조직의 각 부문 (영업, 제조, 연구 등) 과 회사내의 프로젝트들 (아동복, 숙녀복, 정장 등) 이 각각 조직의 이익과 손실에 어떻게
영향을 주는지 알아야 한다는 취지를 설명하고, 경영 대시보드 라는 개념을 통해서 현재 회계 상태를 점검하라는 조언이 나옵니다. 소프트웨어 개발도 마찬가지인데, 완성된 시스템에 영향을 끼치는 각각의 컴포넌트의 상태를
CI 툴에서 제공하는 대시보드 UI 를 통하여 요구조건을 충족하는 상태인지 아닌지를 항상 점검하라는 것이 CI 가 추구하는 목표중 하나죠. 대시보드라는 개념이나 그 원리나 비슷하군요. 어쩌면 CI 가 MIS 쪽에서 그 개념들을 배워왔기
때문일지도 모르겠습니다. TDD 나 Lean 개발도 공업에서 배워온 개념이니까요.
2009.12.09 17:03:00 (*.10.17.150)
김창준 TDD를 복식부기에 비유해 보는 것은 중요한 발상입니다. http://unhandled-exceptions.com/blog/index.php/2009/02/15/uncle-bob-tdd-as-double-entry-bookkeeping/
target=_blank>http://books.google.com/books?id=g_ji7cRb--UC&lpg=PT302&ots=vlNszrXz7A&dq=double%20entry%20bookkeeping%20tdd&pg=PT302#v=onepage&q=double%20entry%20bookkeeping%20tdd&f=false
XPE 2번째 판에 보면 XP의 원칙 중에 "잉여"(redundancy)라는 것이 있습니다. TDD에서는 같은 의도를 두 번 서로 다른 방식으로 표현합니다. 한 번은 사용자 입장, 한 번은 공급자 입장. 그런데 이런 잉여를 만드는 데에는 TDD 말고도 다른 방법들도 가능합니다. 짝 프로그래밍도 어떻게 보면 잉여의 한 가지 예이지요.
그리고 TDD를 꼭 협소하게 생각하지 않아도 됩니다. 켄트 벡은 TDDBE에서 다음과 같이 말합니다:
TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap.
"What if I do a paper design for a week, then test-drive the code? Is that TDD?" Sure. it's TDD. You were aware of the gap between decision and feedback, and you controlled the gap deliberately.
XPE 2번째 판에 보면 XP의 원칙 중에 "잉여"(redundancy)라는 것이 있습니다. TDD에서는 같은 의도를 두 번 서로 다른 방식으로 표현합니다. 한 번은 사용자 입장, 한 번은 공급자 입장. 그런데 이런 잉여를 만드는 데에는 TDD 말고도 다른 방법들도 가능합니다. 짝 프로그래밍도 어떻게 보면 잉여의 한 가지 예이지요.
그리고 TDD를 꼭 협소하게 생각하지 않아도 됩니다. 켄트 벡은 TDDBE에서 다음과 같이 말합니다:
TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap.
"What if I do a paper design for a week, then test-drive the code? Is that TDD?" Sure. it's TDD. You were aware of the gap between decision and feedback, and you controlled the gap deliberately.
2009.12.10 00:30:39 (*.33.110.135)
채이아빠 김창준// 저 글은 못 보고 생각했었던 것이었는데 역시 저 혼자만의 생각은 아니었군요. 좋은 정보 감사합니다.
생각해보면 redundancy 가 없는 커뮤니케이션은 기본적으로 fragile 할 수 밖에 없을 것 같네요. TCP/IP 를 지나는 수많은 ACK 패킷들부터 해서, 선생이 학생에게 공부를 가르쳐주고 나면 시험을 보는 행위까지.
생각해보면 redundancy 가 없는 커뮤니케이션은 기본적으로 fragile 할 수 밖에 없을 것 같네요. TCP/IP 를 지나는 수많은 ACK 패킷들부터 해서, 선생이 학생에게 공부를 가르쳐주고 나면 시험을 보는 행위까지.
2009.12.11 10:22:30 (*.132.80.1)
![[레벨:3]](http://old.lameproof.com/modules/point/icons/default/3.gif "포인트:1352point (86%), 레벨:3/30"){kind=icon}
차앙 프로젝트에 TDD를 도입하려고 테스트를 조금씩 하다가..
아예 테스트 프로그램이 만들어져버리더군요.
그러고나니 TDD를 따라하려던거였는지..
그냥 평소 테스트를 위해 프로그램이 추가된것인지에 대한 의미나 경계가 좀 미묘해지더군요. ^^;
아예 테스트 프로그램이 만들어져버리더군요.
그러고나니 TDD를 따라하려던거였는지..
그냥 평소 테스트를 위해 프로그램이 추가된것인지에 대한 의미나 경계가 좀 미묘해지더군요. ^^;