여러가지 경로를 통해서 여러 델 개발자들의 소스를 받아서 분석하다보면, 많은 델 개발자들이 소스 파일 분리를 잘 못하는 것 같다는 생각이 든다. 달리 말하자면, 하나의 소스 파일에 너무나 많은 코드량이 들어 있다는 것이다. 특히, 상당수의 경우, 메인폼 소스 파일의 복잡성은 매우 심하다.

메인폼 소스 파일이 복잡해 지는 이유는 여러가지가 있지만, 메인폼의 가장 주된 역할이 작업폼 처리에 관한 내용이기 때문에, 작업폼 처리 관련 코드들로 엄청나게 복잡해지는 경우가 많다. 예를 들어 작업폼의 생성과 파괴 처리, 메인폼과 작업폼간의 관계 설정, 동일 작업폼이 두번 생성되지 않게 처리, 여러 작업폼이 공통으로 사용해야할 전역변수나 함수,  메인폼 배경 그림 표시하기 등등, 여러 기능들로 인해서 메인폼 소스 파일은 엄청나게 복잡해질 가능성이 항상 농후하다.

메인폼도 복잡해질 가능성이 농후하지만, 작업폼 역시 어찌 보면 마찬가지다. 작업폼에는 여러 Visual, Non Visual 콤포넌트들이 놓이고, 이 콤포넌트들에 대해 이런 저런 이벤트 메서드들을 만들다 보면, 이벤트간의 의존관계가 복잡해지고, 따라서 어떤 이벤트 메서드를 잘못 수정하면 다른 부분이 제대로 동작하지 않는 부작용이 발생하거나, 특정 콤포넌트를 다른 콤포넌트로 대체하려면 연결된 이벤트들의 처리 때문에 난감한 경우가 자주 있다.

델파이든 비주얼 베이직 혹은 파워빌더이던 간에, 윈도우 개발 툴 상당수는 이벤트 메서드 작성이 가장 주된 코딩 내용인데, 여러 이벤트간의 관계가 복잡해져서, 소스 분석이 힘들어지고, 따라서 기능 추가와 디버깅이 매우 힘든 상황에 이르고, 결국 프라젝트 자체를 엄청난 혼란 속으로 빠뜨리는 경우가 종종 있다. RAD는 경우에 따라서, Rapid Application Developing, 즉 신속한 어플 개발의 축약어가 될수도 있지만, Rapid Applaction Disaster, 신속한 어플 재난의 축약어가 될수도 있다는 것이다.

이런 "신속한 어플 재난"을 피하려면 가급적 소스를 간결하게 유지해서 분석 및 수정이 용이토록 해야 한다는 것이다. 따라서, 특정 소스 파일의 코드 내용이 방대하면, 즉 소스 복잡도가 심하다면 소스 파일을 분리할 필요가 있다.

리팩토링(Refactoring)이란 말을 들어본 적이 있다면, 혹은 유지보수 과정 중에, 기존 소스의 엄청난 길이와 이런 저런 이벤트 메서드들의 난무로 인해 소스 분석이 너무 어려웠던 경험이 있다면, 소스 간결성 유지가 얼마나 중요한지 한번쯤 생각해 봤을 것이다.

현대 개발 언어들은 대부분 멀티 모듈 방식, 혹은 멀티 소스 방식을 지원한다. 물론 델파이도 마찬가지다. 그런데 왜 많은 델파이 개발자들이 이러한 소스 분리를 잘 못하는 것일까? 그 이유에는 이런 코드 체계화에 관한 책이, 델파이 분야에는 거의 전무한 것도 그 이유중 하나인 것 같다. 델파이 관련책을 보면 개발 팁에 관한 책은 많으나, 소스를 간결하게 유지하고 체계적으로 정리하는 방법에 대한 책은 거의 본적이 없는 것 같다. 그리고 비베나 다른 언어에서 잘못된 관행을 델파이에 그대로 가져오는 경우도 많은 것 같다.

몇몇 사람들에게 객체지향 개념을 가리키면서, 왜 상당수 사람들이 객체지향을 제대로 적용하지 못할까를 한참동안 고민해 본 적이 있다. 나의 가르치는 방식에 문제가 있는가? 대체 어떤 이유 때문에 객체지향을 쉽게 도입하지 못할까?

최근, 내가 도달한 결론은, 많은 델 개발자들이 소스의 체계적 관리에 상당히 무심하다는 것이다.

객체지향을 터득하려면 먼저 코드의 정반합 이론을 알아야만 한다. 이말인 즉, 소스 파일을 체계적으로 분리하여 연관된 데이타(변수)와 함수를 별개의 소스 파일로 분리할 줄 아고, 연관된 것들끼리는 결합하는 학습이 먼저 선행되어야 한다는 것이다. 클래스 정의란 것은, 연관된 데이타와 이를 사용하는 함수(메서드)를 별도로 덜어내고 이를 묶는 방법이므로, 소스 분리는 어찌보면 객체지향 이해에서 가장 먼저 선행되어야 한다는 것이다.

내가 가르킨 후배 중 하나가, 어느 날 자신이 만든 클래스 소스를 들고 찾아왔었다. 그 후배의 소스를 보는 순간 경악하지 않을 수 없었다. 클래스 구성이 너무 엉망이었기 때문이다. 대체 어떤 클래스가 어떤 역할을 하는지 전혀 생각을 하지 않고, 그냥 클래스 만들기에만 열중한 것 같았다. 왜 이 메서드와 이 데이타를 이 클래스에 둬야하는지, 혹은 저 클래스에 둬야 하는지 깊이 생각을 하지 않았다는 것이다.

자신이 만든 클래스가 뭔가 이상하고 찝찝하다면, 여러분들도 이런 잘못된 소스 분리 혹은 코드 분리를 경험하고 있을지 모른다. 따라서 코드 분리와 소스 분리를 지금까지 등한시 했다면, 이에 대한 책을 구해서 체계적으로 연구해볼 필요가 있다. 이는 결국, 후일 개발 생산성 향상으로 이어지며, 날밤 새워야 하는 시간을 많이 줄여줄 수도 있기 때문이다.

이번에 내가 개최하는 "델파이 객체지향 실무 및 리팩토링"의 주된 내용으로 이러한 내용들을 다루고자 한다. 통신, FA, DB 같은 특정 분야에 대해서는, 나보다 더 실력이 있고 뛰어난 개발자들이 매우 많을 것이다. 그러나, 소스의 체계화에 대해서는 매우 오랜 경험이 있는 개발자들도 잘못된 관행으로 코딩하는 경우를 자주 본다.

이번에 본인이 개최하고자 하는 세미나 홍보성 글로 전락되었지만, 이번 세미나가 소스와 코드의 체계화에 대해서 깊이 생각해보는 기회가 되었으면 하는 바램이다.

다음 강좌에서는, 소스를 체계적으로 분리하는, 간단하면서도 쉬운 몇가지 방법들을 알아 보자.

http://cafe.daum.net/delphinegong