형상 구성단위로 TestCase 유용할까?
한국의 마틴 파울러가 되기
지난 글에서 인용했던 Kent Beck의 그림을 다시 보면 현실의 변화를 시스템으로 구현하는 일은 지난 글에서 다룬 사업 관리의 관점에서도 그대로 효용성이 있습니다. 또한, 개발자 입장에서 자기 기준에 의해 프로그램을 추가한 상황에도 문제없이 적용할 수 있습니다.
충분히 추상적인 그림이라 해석의 여지가 많습니다.
Code Smells로 기술 부채를 분해하여 대응하기
여기서 지난 연재 과정에서 떠오른 아이디어를 다시 강화할 수 있습니다.
Kent Beck의 그림을 다음과 같이 살짝 바꿔보면 과업의 단위로 Code Smell이 효용성을 가질 수 있습니다.
형상 구성단위의 필요성
다만, 그림에 드러나지 않은 맥락을 떠올리면 허점이 있습니다. 생각이 생각을 만들어 내고 있습니다. 형상 변경에 대한 추적은 존재하지 않습니다. 과거 기록을 활용하도록 하겠습니다.
The term configuration item (CI) refers to the fundamental structural unit of a configuration management system.
2004년에 Configuration Identification에 대한 개념을 익히고 형상관리계획을 수립하던 일이 있었습니다. 사실상 IT 컨설턴트로서 눈을 뜨던 때였는데, 당시 제가 느낀 이론과 현실의 괴리는 엄청났습니다. 그 후에 효용성을 까맣게 잊었던 Configuration Identification에 대해 다시 떠올린 시기는 바로 올해 4월 <Configuration Item과 설정 경험의 진화>를 쓸 때입니다.
그런데 4월만 해도 산업 현실이 어느 정도 변화가 있었나를 살펴보는 정도였습니다. 3개월이 지난 지금은 제가 그간 테스트에 대한 글을 쓴 탓으로 우연적인 발견에 의한 가정이 하나 생겼습니다. 바로 TDD를 하면 생기는 TestCase가 매우 훌륭한 CI일 수 있다는 점입니다.
통제 모형 정의의 필요성을 깨닫다
어딘가 좀 아이디어가 빈약하다는 찜찜함을 지울 수 없었는데, 뜻하지 않은 곳에서 힌트를 얻었습니다. 유효한 생각인지는 검증이 필요하지만, 김상욱 교수님 물리학 강의에서 소개한 뉴턴의 프린키피아 내용 일부입니다.
뉴턴은 우리가 경험할 수 없지만 수학적인 절대적인 시간과 공간을 우리가 체감하는 상대적인 시간과 공간으로 구분했습니다. 이는 마치 우리의 현실과 통제 목표를 별도로 분리해서 존재시켜야 한다는 사실을 알려 주는 듯합니다.
