. 분할의 이점

지금까지 힘들게 만들어온 Dangeun 프로젝트를 보면 구성 모듈이 몇 개 되지 않는다. 컨트롤측에 ApiEdit Parse가 있고 호스트쪽에 Dangeun Util이 있으며 미리 컴파일된 헤더를 위한 stdafx 모듈과 리소스가 있을 뿐이다. 이렇게 구성이 간단하기 때문에 실습하기에는 편리했지만 이런 구조는 이후의 프로젝트 유지, 보수에는 대단히 불리하다.

ApiEdit.cpp는 컨트롤의 거의 모든 코드를 가지며 약 5400줄 정도 되고 Dangeun.cpp는 호스트의 모든 코드를 포함하고 있으며 무려 8200줄이나 된다. 이 프로젝트가 관리하는 파일 입출력함수, 각종 설정 대화상자들, 심지어 네트워크 액세스 함수들까지 모조리 이 모듈에 다 작성되어 있어 어떤 함수가 어떤 기능에 사용되는지를 파악하기가 어렵다.

그래서 여기서는 더 이상의 기능 추가는 하지 않고 앞으로의 코드 유지와 보수를 위해 모듈을 잘게 분할하기로 한다. 객체화도 같이 병행하면 좋겠으나 근본적인 구조를 바꿔야 하기 때문에 현재 단계에서는 어렵고 일단 모듈 분할만 해보도록 하자. 모듈을 분할하면 다음과 같은 이점이 생긴다.

 

첫 번째로 가장 두드러지는 효과는 컴파일 속도가 빨라진다는 점이다. 단 한 바이트를 고쳐도 8200줄을 다 컴파일해야 했으나 모듈이 분할되면 수정된 모듈만 컴파일한 후 링크하게 되므로 자연히 컴파일 속도가 빨라질 수밖에 없다. 지금 이 정도 규모에서는 컴파일 시간이 그다지 중요하지 않지만 프로젝트가 더 커지면 전체 빌드를 하는데 1분 이상이 소요될 수도 있다. 한번 수정한 후 1분을 기다려야 결과를 확인해 볼 수 있다면 지루하기도 하거니와 컴파일하는 중에 뭘 고쳤는지 잊어버리게 될 것이다.

두 번째로 관련된 함수들을 한 모듈에 모음으로써 모듈을 논리적으로 구성할 수 있게 된다. 설정과 관련된 함수들과 타입이 한 파일에 모여 있으면 설정 관련 코딩을 할 때 이 모듈만 집중적으로 수정할 수 있으며 원하는 부분을 찾기도 쉬워진다. 특정 기능에 버그가 발견되었다면 관련된 모듈만 집중적으로 디버깅하여 버그의 범위를 좁히기도 쉽다.

세 번째로 프로젝트 규모가 커지면 여러 사람이 분담 작업을 하기가 쉬워진다. 네트워크 전문가는 네트워크 모듈만 열심히 작성하고 메인 유저 인터페이스 개발자는 UI 모듈에만 신경쓰면 된다. 각자의 모듈에 대해서만 작업한다면 두 모듈을 동시에 개발하는 그룹 작업도 가능하며 문제가 생겨도 책임소재가 분명하다.

 

Dangeun11 프로젝트를 복사하여 마지막 프로젝트인 Dangeun12를 만들고 분할을 해보도록 하자. 다음은 분할 계획표이다.

 

기존 모듈

파생 모듈

Util

Mru, Option

Dangeun

Config, FileWnd, Find, Internet, Print, Project, ToolBar

ApiEdit

AeUtil

Parse

파생 모듈 없음

 

주로 Dangeun.cpp를 잘게 분할하는데 적당히 다루기 쉬운 단위로 분할을 하고자 한다. 좀 더 잘게 나누려면 분석기별로 하나의 모듈을 만들 수도 있고 취소 레코드나 정렬정보를 별도의 클래스로 정의할 수도 있을 것이다. 그러나 지나치게 잘게 나누면 컴파일러는 좋아하겠지만 실습하기에는 오히려 번거로운 면도 있다.

모듈 분할을 하는 방법은 아주 원론적이다. 함수나 클래스의 기능에 따라 헤더 파일과 구현 파일을 만들어 프로젝트에 추가한다. 이때 추가된 모듈에 대해서도 미리 컴파일된 헤더를 사용하도록 옵션을 조정해야 한다. 헤더 파일에는 함수, 타입을 선언하며 구현 파일에는 함수의 본체를 작성한다. 이미 작성된 코드를 나누는 것이기 때문에 잘라내기, 붙이기 작업만 하면 된다. 각 모듈이 어떻게 분할되는지 보도록 하자.