SmalltalkBestPracticePatterns:2.2

From 흡혈양파의 번역工房
Revision as of 04:25, 6 July 2013 by Onionmixer (talk | contribs) (SBPP 2.2 패턴들이 작용하는 이유 페이지 추가)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
2.2 패턴들이 작용하는 이유

패턴들이 작용하는 이유

여기 중요한 가정이 하나 있다: 객체는 너무나 많은 작업을 할 수 있다. 모델링(model)할 새 영역은 항상 존재할 것이므로 이러한 가정은 애플리케이션의 수가 한정되어 있다는 의미라기보다는 애플리케이션과 상관없이 객체의 동일한 구조가 계속해서 나타난다는 의미다. 객체들의 양식에서 발생하는 문제는 보편적이다. 당신은 클래스의 이름을 명명하고, 상속과 위임을 통해 클래스를 연관시키고, 동일한 클래스와 다른 클래스에 메소드를 연관시키며, 변수의 이름을 지정하는 등의 작업을 해야 한다. 패턴은 이러한 문제들과 문제 해결을 위한 접근법을 기록한다.


예전에는 시스템 개발 시 컴퓨터와 통신하는 일이 가장 힘들었다. 다년에 걸친 프로그래밍 언어, 프로그래밍 환경, 프로그래밍 스타일의 개선은 컴퓨터에 명령 시 직면하던 장애물을 거의 제거해주었다.


본래 가장 힘든 문제가 해결되면 다른 문제가 또 드러나게 되어 있지 않은가. 소프트웨어 공학에서 다음가는 문제는 인간의 의사소통이었다. 개발 예산의 70%를 유지보수(maintenance)에 소모한다고 치면, 어리숙한 관리자(maintainer)들이 문서더미를 처리하고 코딩하여 본래 프로그래머의 의도를 발견해야 함을 뜻한다. 재사용이 널리 퍼지면서 이 문제는 악화되었다. 하나의 개발품에 더 이상 한 명의 관리자로 그치지 않고, 수백 명, 수천 명, 수십만의 교정자들이 추출자(abstractor)의 의도를 이해하고자 노력하는 현상이 발생한다.


의사소통을 향상시키기 위해서는 두 가지 방법이 있다; 대역폭을 증가시켜 더 많은 비트를 전달하도록 하거나, 송신자와 수신자 간 공유하는 컨텍스트를 증가시켜 동일한 비트가 더 많은 의미를 담도록 만드는 방법이다. 첫 번째 방법은 특히 재사용 시 비실용적이므로 (한 명의 개발자만 다수의 조각으로 자를 수 있기 때문에) 다른 방법을 찾아야 한다. 어떤 프로세스든 최적화를 원한다면 공통 사례(common case)가 일반 사례(general case)보다 어떻게 더 단순한지를 알아내는 전략을 가장 먼저 취한다. 소프트웨어 공학의 경우, 일반 사례는 프로그래밍 언어가 된다. 하지만 우리가 문제를 해결하기 위해 프로그래밍 언어까지 되돌아가는 경우는 드물다. 지난주와 작년에 우리가 한일, 또는 친구가 한일을 살펴보는 등의 방식을 취한다.


작지만 유대가 긴밀한 개발조직은 이러한 최적화가 누적되는 효과를 보인다. 모두들 동일한 경험을 공유하기 때문에 단순한 단어나 문구만으로도 큰 의미를 지닐 수 있다. "문제가 생겼어요. 어떻게 해결하죠?" "그래픽 에디터를 사용해보지 그래요?" "그렇군요! 좋은 생각이에요!" 작은규모의 개발조직들은 이러한 중요한 "기발한 문구"들을 생각해낼 때 놀라울 정도로 생산적으로 변한다.


이 정보를 전송하는 데에 언어적 전이(oral tradition)에 의존 시 두 가지 문제점이 있다. 첫째, 팀의 구성원들의 대화는 대화에 처음부터 참여하지 않은 사람이 거의 이해할 수 없을 정도로 변한다. 둘째, 프로세스가 급증하지 않는다. 사적 언어의 이점을 포기하지 않는 한 팀이 크게 성장할 수가 없으며, 한 팀의 경험이 다른 팀으로 쉽게 전달되지 않는다는 단점이 있다.


패턴은 일반적 습관을 포착하고 전송하기 위한 문학 형식이다. 각 패턴은 재발하는 문제, 문제에 대한 해결방법을 구성하는 방법, 그리고 해결방법이 왜 적절한지를 기록한다. 그 이유를 납득시킴으로써 패턴은 해결방법이 언제 적절한지 또는 왜 적절한지를 논하지 않은 채 해결방법만을 지시하는 대부분의 "스타일 가이드"의 문제를 피한다. 패턴에서 명명된 이름에 반복적인 문제가 발생할 경우, 패턴을 읽은 후 이 패턴에서 필요로 하는 해결방법이 적절하다는 확신이 있어야 하며, 적절하지 않다면 그 이유도 인식해야 한다.


패턴은 존재하며 모든 개발 단계에서 연계될 수 있다. 시스템 개발을 계획하고 순서대로 배열하는 방법, 특정 클래스 라이브러리로 애플리케이션을 생성하는 방법, 새 객체를 설계하는 방법, 포맷 소스 코드가 가능한 한 명확하게 통신하도록 포맷하는 방법을 알려주는 패턴들도 있다.


각 패턴들은 개발에 유연한 방편을 형성하도록 서로 엮일 때 가치가 커진다. 개발에 대한 전문 지식은 문제를 어떻게 해결해야 하는지, 어떤 문제를 안전하게 간과하는지 인지하는 데에 따라 좌우되곤 한다. 각 패턴이 그것을 선행하고 완료시킨 패턴들의 이름을 정하면 소프트웨어 공학 전문 지식을 수집하여 풍부한 언어를 낳게 된다.


Notes