[1002] : exp_i
by 1002
카테고리
이전블로그
이글루링크
최근 등록된 덧글
아니. 예전에의 흔적일 ..
by 1002 at 02/13
블로그 시작하신건가요?
by FnWinter at 02/08
"그때마다 새로운 것을 ..
by 테이_ble at 11/17
최근 등록된 트랙백
tdd에서의 리팩토링은..
by C++ 프로그래머 티오
이글루 파인더

rss

skin by 꾸자네
자신의 프로그램에 목숨을 걸어야 한다면..
자신의 프로그램에 목숨을 걸 수 있습니까


그런데 몇 가지 조건이 더 주어집니다. 자신은 예컨대 2시간 후에 수술을 받아야 합니다. 그때 사용하는 수술 기계에 이 프로그램이 중요한 역할을 하게 됩니다. 자신이 직접 작성한 프로그램으로 수술을 받는 것입니다. 프로그램이 오작동하면 자신은 죽을 수도 있습니다.

이 프로그램이 정상작동한다는 것을 최대한 보장하기 위해 프로그래밍 전, 프로그래밍 중, 프로그래밍 후 각각의 시기에 어떤 일을 하시겠습니까? (프로그램 F를 작성하는 것이 이 오디션의 목표는 아닙니다 -- 따라서 오디션 중에 그 프로그램을 작성할 필요까지는 없습니다)



나도 방법을 궁리하던 중.. 어떤 것이 가장 중요한 컨셉이 될까 생각하다가 다음을 생각하였다. 테스트가 '무엇을 보장해주어야 목숨걸만큼 용기가 날까?'

프로그램 전 :
Platform 선택, 컴파일러 및 언어 구현물 선택을 신중하게 한다. 2시간 정도는 메모리가 새도 버틸 수 있는 언어 선택 (괜히 delete 를 명시적으로 했다가 실수하여 프로그램이 죽으면 난감하므로;) 혹은 C 로 짜더라도 시스템 메모리를 2G 이상을 박아놓은 뒤, delete 나 free 명령을 아에 안쓰던지.; 수술 시간 내에만 최대한 안정성이 보장되면 된다.
시간이 중요하므로 개발환경은 최대한 들일 수 있는 비싼 환경을 들인다.

디자인과 관련, 컨커런시 문제 등은 최대한 없도록 싱글스레드로 구현한다.

이 일에 가장 최적일 개발자를 돈을 주고 고용을 하여 찾거나, '내가 직접 구현한다'

프로그램 중 :
만들 수 있는 유닛테스트는 다 추가해보며 작성한다.
도구를 돌리는데 걸리는 시간이 짧다면 정적 분석도구도 이용하여 돌려본다.

프로그램 후 :

이상적이라면, 나와 비슷한 신체를 가진 마네킹을 수십 개 준비한 뒤 (수술부위에의 구조와 신체에의 구성물질도 최대한 비슷한. 물질이 다르면 수술기계가 수술하는 중의 물리적 영향력이 다를 수 있을테니) 이를 수술기계에 올려놓고 최종 수술과 똑같은 과정을 돌려보게 한다. (수술 시간이 얼마나 걸리는지에 따라 다르겠지만 수술 시간이 아주 짧은 경우) 마네킹 10개 이상에 대해 수술기계를 돌려보고 용기가 난다면 수술을 받겠다.

극단적이라면, 나와 비슷한 신체를 가진 인조인간을 만든 뒤 (무슨.. 영화 '아일랜드' 같은..;) 수술기계에 올려놓고 실험을 해본다. (윤리적 비난 엄청 받겠구나.. -_-;)
by 1002 | 2007/01/12 08:24 | 트랙백 | 덧글(2)
from 켄트 벡이 대답하기 2탄 : TDD 에서의 테스트
켄트 벡이 대답하길 2탄  에서 질문 중 하나에 대한 답변. 그리고 그에 대한 트랙백

Q: TDD의 테스트는 두가지 목적이 있는 것 같다. 하나는 디자인 시의 가이드, 또 하나는 리팩토링 때의 회귀 테스트. 전자의 경우에 나온 테스트는 리팩토링의 안전성을 보장하기에는 성글어서 문제가 될 수 있다. 그렇다면 어떻게 해야 하나?

"켄트 말하길, 디자인, 테스트의 분리가 이상하다. 단계(phase)를 만들어 넣는 것 같다. 나는 중요한 테스트라면 처음 테스트를 만들 때 다 한다. 나중에 깨질 것 같은, 불안한 부분이 있을 때 뒤로 미루지 않는다. 그러나 리팩토링할 때 뭔가 새는 부분을 찾았다면 나는 새로운 것을 배운 것이다."


각각의 말들에 대해서 고민을 하게 되다.
'디자인, 테스트의 분리가 이상하다. 무언가 단계를 만들어 넣는 것 같다.'

TDD 를 진행하는 중에 최종 코드 상으로는 그 둘이 구분되지 않는다. 다만, 이 코드를 작성하는 과정 중에 사고의 분리가 있거나 없거나 하는 것으로 이 단계가 구분된다.
개인적인 경험으로는, '디자인 과정 중에 나온 테스트' 의 경우 디자인을 우선시 하기 위해서 테스트 코드에의 넣는 입력 대비 아웃풋을 간략히 하고, 구현을 진행한다. 구현 중 Fake it 을 하더라도, 최종적으로 Real Implementation 을 진행한다. 이 경우를 생각하면
 1. 코드 구현 상으로는 Real Implementation 으로, 이미 완성된 결과물이 나온다. (코드를 작성할 때 당시 생각할 수 있는 선 내에서)
 2. 그럼에도 불구하고, 처음에의 테스트 코드 수가 그대로 유지되는 경우가 많다. 테스트 작성은 비용이 들면서도, 이 비용 자체는 실제 구현을 위한 직접비용이라기 보다는 간접비용에 더 가까우므로, 추가 테스트를 잘 작성하지 않으려고 한다.
여기서 2번째 부분, TDD 초심자와 TDD 에 익숙한 사람 둘 다 실수 할 가능성이 높은 상황일 것 같다. 아마 대부분의 개발자의 경우 2번에서 테스트의 수가 멈춰버릴 것이다. 그리고 TDD 에 익숙하다고 생각하는 사람들은 '이 부분은 안전해' 하면서 테스트를 추가 작성하지 않고 Test Step 을 깨고 Real Implementation Step 으로 진행할 경우들이 있을 것이다. 그리고 Real Expert 는 추후 요구사항이 늘어날 때, 2번 파트와 관련하여 관련되는 객체들을 다시 찾고, 아는 만큼의 예외들에 대한 테스트들을 추가적으로 작성할 것이다.
 * 오히려 'Fake it - real implementation' 혹은 'triangulation - real implementation' step 으로 TDD 를 진행하는 사람의 경우 2번에서의 실수를 방지할 것 같다는 생각할 것 같다.

'중요한 테스트라면 처음 테스트를 만들 때 다 한다. 나중에 깨질 것 같은, 불안한 부분이 있을 때 뒤로 미루지 않는다.' - '아는 만큼의 Courage를 가지고 TDD를 진행한다.' 라고 해석할 수 있을까. 이에 대해서 고민되는 점은, '현재 프로그램 중 불안한 부분이 있긴 한데, 이에 대해서 테스트로 작성할 지식이 없다면? 어떻게 서술해야 할지 모르겠다면? 그럼에도 리팩토링은 진행해야 될 것 같은데.. ' Courage 와 Fear 간의 대립이 시작된다.

그리고 그에 대한 대답이 다음에 이어진다.

'리팩토링할 때 뭔가 새는 부분을 찾았다면 나는 새로운 것을 배운 것이다.'

Courage 를 가지고 리팩토링 스텝까지 진행을 했음에도 불구하고, 실제 리팩 전-후가 잘못되는 경우는 사람인 이상 누구나 있을 수 있다. 그 경우가 발생했을 때는 보통 사람들은 '아.. 이런. 리팩토링은 많이 위험하구나' 하며 Discourage 되고, 몇몇 사람들의 경우  좀 더 간단하고 쉽게(거기에 시니컬 함을 덧붙여) 'TDD 나 Refactoring 은 여기까지가 한계구나. 사람인 이상 리팩하다 실수 밥먹듯 할텐데. 이렇게 위험한 것을 어떻게 써?'

그리고 켄트 백은 간단히 '그때마다, 나는 새로운 것을 배운 것이다' 라고 이야기한다.

----

답을 듣는 중에 다음과 같은 목소리가 들려온다. 'Fear를 구체화하여 Test 화 하라고 했는데. 책을 찾아보거나, 다른 사람들과 대화를 하거나. 실험을 하거나, 더 공부를 하거나. 왜 그러한 시도들을 해보지 않는가?'
 
by 1002 | 2006/11/11 15:44 | 트랙백(1) | 덧글(1)
<< 이전 페이지 다음 페이지 >>