Code Quality 높이기

성공한 (소프트웨어)프로젝트건 성공한 것처럼 보이는 프로젝트이건
독립적인 프로젝트는 없다. 이후의 프로젝트에서 이번의 프로젝트를
이용하거나 확장 하는 경우가 많고 이 프로젝트의 유지 보수차원에서 또하나의
프로젝트가 생기기도 한다. 1990년대 이후 유행한 컴포넌트 개념 때문에
재사용의 이슈는 항상 따라다닌다.

재사용에서 가장 중요한 것은 무엇인가? 바로 재사용할 코드의 품질이다.
재사용가능하도록 만들어진 코드를 이용하는 것과 아무렇게 만들어진
코드를 이용하는 것은 개발자들에게 있어서 그야말로 하늘과 땅 차이다.

Code Quality이 낮은 프로그램을 분석하고 그것을 재사용하는 것은
프로그램을 아예 처음부터 만드는 것보다 더 어려운 일이라는 것은 불변의
진리이다. 그러나 안타까운 것은 많은 프로젝트들이 관리의 측면에서
만 코드 재사용이 논의 될 뿐 개발자들의 수준에서는 거의 "무작정
재사용 하라"라는 강요에만 그친다는 것이다. 이 말은 코드 재사용의
여부가 프로그래머 수준에서 동의를 구하고 있지 못하다는 것이다.

현실적으로 다음 프로젝트의 발주를 할때 프로그래머에게 일일이
코드를 보여주며 이것은 재사용가능한가? 라는 질문을 던져 그 동의를
구하는 과정은 개입할 여지가 거의 없다. 더군다나, 관리 문서상에는
코드 재사용의 여부가 나타나지 않는다.

어떤 기관에서는 코드의 품질을 높이기 위해서 "peer inspection"이라는
프로세스를 두고 지키려고 하지만, 아쉽게도 코드를 직접 작성한
프로그래머가 관리자의 틈에 껴서 이런 프로세스를 수행하여 그 프로세스의
뜻한 바를 달성하기에는 시간적 여유도, 코드를 완벽하게 이해하지 못하는
관리자를 설득할 힘도 없다. 결국 이름만 peer inspection일 가능성이 많다는
것이다.

재사용 가능한 코드와 그렇지 못한 코드에 대한 가격의 차이가 있는가?
필자는 아직 그런 차이를 두고 있는 프로젝트를 본 적이 없다.
잘했다 못했다의 차이만 있을 뿐...

어떤 기관에서 제 2차 프로젝트를 기획하고 있는 관리자의 말이다.
"1차에서 나온 코드를 재사용 하면 되므로, 2차의 프로젝트 비용은
원래 책정된 데서 한 20%정고 깍으면 되겠네요?"

개발 회사 왈 "1차에서 나온 코드를 재사용하는 대신 프로젝트 비용을
20% 깍겠다구요? 어떻게 그런..."

관리자 왈 " 1차 프로젝트에서 사용한 방법론이 CBD 아니었던가요?
그럼 당연히 재사용 가능한거잖아요"

개발회사 "..."

개발회사는 이런 경우를 한두번 겪은 것이 아니다.
CBD를 썼다고 한 코드를 받아서 재사용하고자 코드를 들여다 보고
코드를 아예 다시만드는 것이 낫다는 생각을 한 것이 한두번이 아니었기 때문이다.
(그래서 요즘 framework이라는 것이 다시 이슈가 되나보다)

악순환의 반복이다.

어떻게 이를 해결 할 수 있을까?

정교한 문서작업과, peer inspection으로는 현실을 제대로 반영하여 해결할 수 없다.
인간의 본연의 하고자하는 의지를 반영하지 못하는 방법론에서
CBD아니라 CBD할아버지가 쓰였다고 하더라도
제대로된 코드가 나올 수 없다.

XP는 이러한 문제를 원천적으로 해결한다.
왜냐고?

기능테스트 통과만을 목적으로 대강만들어진 프로그래밍으로는
XP자체를 수행할 수 없기 때문에다. 즉 대강 대강이라는 자세로는
프로젝트 자체를 진행할 수 없기 때문이다.

peer inspection이니 CMMI이니 하는 비싼 정책을 도입하는 것 보다
Code Quality 향상을 위해서는 XP를 도입하는 것이 더 효과적일 것이다.