코드 모듈화를 위한 일반적인 원칙

코드를 모듈화한다는 것은 알고리짐의 기본원칙에 입각한 것이다. 즉, "나누어서 정복하라"라고 하는 알고리즘에서 기인한 것이라고 할 수 있는데, 현업에서 이를 쉽게 적용하기가 쉽지 않다.
이론상으로는 가능한한 작은 토막을 내어서 모듈화를 시키는 것이 좋다고 하지만 실제로는 업무를 진행하는 데 있어 이론이 정확하게 적용되는 것은 아닌 것이다.

그러함에도 개발자들은 자신의 코드를 통해서 이렇게 제시된 이론에 근접한 코드를 짤 수 있어야 한다고 생각한다. 쉽지 않은 길이지만 경력이 쌓여갈수록 이러한 이론에 접근하여 잘 짜여진 코드를 만들수 있어야 하는게 개발자의 길이기도 하다.

그러면 간략하게 모듈화에 대해 메모를 해보자. C 계열의 언어에서는 funcation이나 Implementation 코드로 구현이 가능하고, 자바언어에서는 method나 클래스로 구현이 가능하다. 이렇게 언어에 국한적인 원칙 외에 일반적인 원칙을 간단하게 메모해 둔다.

1. 코드의 공통된 부분을 찾아서 모듈화 시켜라
이것은 가장 일반적인 원칙 중에 하나인데 개발자들에겐 당연한 일인듯이 여기진다. 그러함에도 실제 코드를 살펴보면 상당부분 중복된 부분을 살펴볼 수 있는데, 첫째는 잘못된 설계에서 기인하고 때로는 지나친(잘못된) 요구사항 중에 실수를 유발하기도 한다. 둘째는 일종의 리팩토링을 하지 않았다고 볼 수 있다. 이미 짜여진 코드는 완벽할 수 가 없다. 그럼으로 때에 따라서는 코드 리팩토링을 통해서 공통된 부분을 찾아서 모듈화를 진행시켜야 한다.

2. 디자인 패턴의 적용(OCP : Open-Closed Principle 의 적용)
디자인 패턴의 정의를 내릴 수는 없지만 쉽게 이해할 수 있는 바로는 우리보다 휠씬 똑똑한 사람들이 개발을 진행하는데 있어 공통적으로 사용되거나 자주 사용되는 원칙을 정리해 둔 것이라 할 수 있다. 따라서 디자인 패턴의 적용은 대부분 리팩토링이나 모듈화를 진행하는데 있어 아주 중요한 역할을 한다.
여기서 디자인 패턴에 대한 부분을 언급하기에는 무리가 있음으로 OCP에 대한 자료를 소개하는 것으로 대체한다.
[객체지향 SW 설계의 원칙] ① 개방-폐쇄 원칙
[객체지향 SW 설계의 원칙] ② 사례연구, 단일 책임 원칙
[객체지향 SW 설계의 원칙] ③ 인터페이스 분리의 원칙
[객체지향 SW 설계의 원칙] ④ 리스코프 치환 원칙

위의 연재에서 제시하는 대부분의 원칙들이 디자인패턴에서 제시하는 원칙과 일치하는 것을 알아둬야 한다. 끝으로, 여러가지의 디자인 패턴중에 프로젝트에 맞는 패턴을 적용할 줄 아는 능력을 키워야하겠다.

개발자의 초식, 디자인 패턴「그러나…」

3. 잘 구성된(짜여진) 코드 분석
잘 짜여진 코드는 위의 두 원칙에 입각하여 제대로 된 코드를 제시하는 것을 볼 수 있다. 이전에 자바 진영에서는 SUN Microsystems에서 Blue-print로 제시된 petstore가 있었는데, 이 소스는 잘 짜여진 소스일 뿐 만 아니라, 이후에 다양한 프레임워크를 개발한 곳에서 재구성되고 또 재구성되어 각 프레임워크에 맞는 형태로 개발되어져 있다.
따라서 당연히 발전에 발전을 거듭하여 우리가 분석해 보고 따라해 보기에 좋을 것이다.

4. 개발업무의 적절한 분석
모듈화의 일반적인 원칙을 제시하면서 개발업무에 대한 적절한 분석을 제시하는 것이 이상하게 여겨질런지도 모르겠다. 하지만 업무에 대한 적절한 분석은 설계와 구현으로 직결되는 것이기 때문에 이미 분석된 예제코드와 같은 것이 아니고, 자신이 직접 설계하고 구현해야 하는 프로젝트에 맞는 업무일 경우 이에 대한 분석은 보다 확실히 이루어져야 한다.
물론 우리나라의 사정상 제대로된 요구사항이나 업무분석이 이루어지기 힘들다는 것을 알고 있다. 여기선 주변의 환경적인 요소를 이야기하는 것이 아니라, 개발자에게 있어 필요한 사항을 이야기하는 것임으로 집고 넘어가야 한다.

예들들면, 업무를 어떻게 나누느냐에 따라서 비지니스 로직이 변경되기 때문에 그에 따른 도메인이나 퍼시스턴스 영역들이 변경될 가능성이 높아진다. 사실은 도메인 설계시에 다양한 요구사항에 맞는 설계를 해야겠지만, 현실은 그렇치 않음으로 생각을 역으로 바꾸어 업무처리 중에 공통된 부분과 모듈화 할 수 있는 부분을 찾아서 처리해 주는 것이 좋다.

5. 유틸리티 코드 및 자료구조(또는 Collection) 코드의 적절한 이용
약간은 엉뚱하다. 하지만 오랫동안 개발해 온 사람들을보면 나름대로의 유틸리티 코드를 가지고 있는 것을 본다. 예를들면, Encoding, Decoding 코드라든지, ByteUtil 같은 코드, 그리고 자료구조의 구현과 같은 코드들이다.
자료구조는 알고리즘 이전에 반드시 필수적으로 봐야하는 과목(?)으로 개발을 하면 할 수록 알고리즘과 함께 중요하게 여기지는 파트이다. 자바에서는 이러한 자료구조와 같은 것들을 Collection 객체에서 많이 구현해 주고 있다. 그러함에도 자신에게 맞는 코드를 구비할 필요가 있다. 당연히 Collection 클래스들을 이용하는 것이 좋다.

글을 적음에 있어 약간의 즉흥성이 발동을 했다. 오늘 업무를 진행하다가 느닷없는 수정사항으로 어떻게 처리를 할까? 하면서 코드를 살펴보던 중에 중복된 업무에 대한 처리를 이루어지는 것을 보면서 나름대로의 모듈화를 진행하고 테스트 및 배포를 완료해 놓고 이 글을 작성하기 때문이다.
평소엔 전혀 생각지도 못했던 원칙들이 글을 작성하면서 내 스스로에게 전달하고픈 메시지가 되어 버렸기도 하다. 한편으론 사견이라 할 수 있지만 많은 사람들에게 조금이라도 도움이 되었으면 하는 바램이다.

- Reference
  http://www.wiseant.net/tc/wiseant/124
   

[출처] 코드 모듈화를 위한 일반적인 원칙|작성자 조영현