감리에 대한 단상

프로젝트 진행에
가장 많은 지식을 가지고 있느 사람은
그 어느 누구도 아닌 바로 프로젝트를 진행하는 당사자 입니다.

감리의 가장 기본 원칙은 상식선에서 첨부터 감사하는 것이 아니라
하기로 정의한 것을 제대로 했냐라는 것을 감사하는 것입니다.

이런 감리를 위해서 조언을 하기로 했다면 이 선에서 조언을 해주시는 것이
맞다고 봅니다. 어느 프로젝트에나 불합리성은 존재합니다.
개발 자체도 그런 것이 있을 수 있습니다만, 소위 말하는 이바닥의 생리상
불합리가 생기는 것이 다반사일 듯합니다.

더군다나 소프트웨어 공학에 대한 학문이 뿌리가 거의 없는 덕에
우리나라에는 공학적 원리를 제대로 가지고 접근하는 사람이 없습니다.
공학적 원리를 제대로 가지고 말을 할려면 이론적 근거를 대고 말을 시작해야할 것입니다.

그렇게 말을 하지 못할 것이면,

프로젝트에서 하기로 한것을 최대한 존중하면서
그 테두리 안에서 되어 있나 되어있지 않나를 검사해야 할 것입니다.

자신의 지식과 프로젝트 에서 하기로 한 것이 맞지 않은 부분은
왜 라고 하는 물음을 먼저 던져야 할 것입니다.

왜라는 것에 제대로된 답을 얻지 못했다면
자신의 지식에 비추어서 이렇게 하라고 할 것이 아니라
프로젝트 전반을 모두 파악한 다음에 그 바탕으로 이렇게 하라고 해야할 것입니다.

하루종일 우리의 목소리가 아니라 제 3자의 목소리가 낭자한 오피스텔에서
프로젝트 참가자들이 스트레스를 안 받을 수 없습니다.

OCP 등..

XP를 효과적으로 수행하고자 한다면..
" Robert C. Martin"디자인 패턴 책을 꼭 보길 권한다. ( 굳이 " Robert C. Martin"의 책을 언급한 이유는 제일 재밌어서)

둘이서 머리를 맞댄다면, 무엇에 대해서 머리를 맞댈 것인가? 단순이 타입이 정확이 써졌나, 캐스팅이 제대로 되고 있나. 어사인이 어떤가 뭐 이런 거면 사실 혼자 하는 것이 좀더 효율적일지도 모르겠다.

둘이서 머리를 맞대고 할만한 것은 좀더 복잡 다단하고 둘의 머리를 모으면 그로테스크한 결과물이 나올 듯한 거리이면 그 효과가 더욱 커질 것이다.

객체 모델링이 그런 것이 아닐까 한다. 특히 처음부터 모든 것을 개발하는 (COTS를 사용하지 않는 ..)곳에서는 고객의 말, 즉 Use case속의 시나리오를 보고 객체를 도출하고
(ICONIX 프로세스를 아는 분은 이런 과정의 지리함과 논리적이지 못한 순간의 실수가 가져오는 엄청난 번거로움을 잘 알 것이다.)그 객체간의 관계 (cardinality 등을 포함하여)를 지은다음에 패턴을 적용하고 클래스 다이어그램, 혹은 시퀀스 다이어그램으로 모델링을 하는 과정을 힘들게 거쳐야 한다.

이런 경우, 어떻게 모델링을 하느냐에 따라서 프로그램 산출물의 품질 요소는 매우 큰 편차를 보일 수 있다. 비록 같은 기능을 보이고 있다고 하더라도 말이다. 그리고 본 책에 나오는 리팩토링의 여지도 케이스마다 매우 달라진다.

다시말해 처음에 어떻게 객체를 정의하고 디자인 패턴을 대입하느냐에 따라서 잘만든 코드와 그렇지 않는 코드의 격차가 커진다는 것이다. 모델링이 잘못 된 코드는 수정이 힘든 것을 물론이겠거니와, 디버깅시에 트레이싱하는 것도 그다지 쉽지 않다. ..

예르 들자면 마틴의 책에는 OCP 원리를 비롯하여 다양한 원리들을 실전에 적용할 수 있는 형식으로 설명을 하고 있다. (OCP 원리란 Open to add, Close to modification로 기능 추가는 쉽게 할 수 있으나 수정을 배재하는 원리를 말한다..)

코드화 하는데 매우 많은 경로가 있는 객체 모델링 그리고 그에 따른 코드 패턴의 적용, 그리고 베스트 프렉티스와 원리들.. 이런 것을 모두 고려한 코딩을 하는 것은 큰 정신 노동이 아닐 수 없다. 둘이서 하는 페어 프로그래밍은 이러한 정신 노동의 부담을 덜어주며 관련된 XP의 원리들은 최적화된 산출물을 얻을 수 있도록 해준다. (이런 의미에서 XP 참가자들은 원숙미를 자랑하는.. 적어도 객체 모델링으로 대화를 할 수 있는 사람이어야 하지 않을까 한다.)