TheArtandScienceofSmalltalk:Chapter 11
- 제 11 장 스몰토크의 예술 - 입문
스몰토크의 예술 - 입문
본 저서의 제 1부에서는 스몰토크 프로그래밍의 '과학'을 살펴보았다. 생산성을 크게 높이기 위해 모든 것을 알아야 할 필요가 없다는 것이 스몰토크의 주요 특징들 중 하나임을 논하였다. 제 1부에서는 시작을 위해 알아야 할 것에 초점을 두었다고 할 수 있겠다.
제 1부에 실린 장들 대부분을 읽고 이해했다면 이제 객체가 무엇인지에 대해서는 어느 정도 잘 이해하고 있을 것이다. 뿐만 아니라 스몰토크 언어에도 익숙해야 하고, 스몰토크 개발 환경의 기반에 만족해야 하며, 스몰토크 클래스 라이브러리의 기능과 가장 중요한 클래스를 알아야 한다. 본문에 있는 예제 혹은 자신이 스스로 만든 복잡한 구성을 이용해 스스로 경험을 어느 정도 쌓았길 바란다.
이론상 그 외 모든 것은 똑같다. 충분한 시간을 들여 경험하면 곧 개발 환경에 익숙해져 광범위한 클래스 라이브러리에 대한 지식을 구축할 수 있을 것이다. 그보다 더 중요한 것은, 능숙한 스몰토크 개발자들이 디자인과 프로그래밍 활동을 설명 시 항상 사용하는 개인적 경험을 구축할 수 있을 것이다. 스몰토크 프로그래밍을 그토록 생산적이고 보람 있게 만드는 것은 이러한 두 번째 유형의 지식이 스몰토크의 기본적 유연성 및 힘과 결합될 때이다. 이러한 지식 유형을 스몰토크의 '예술'이라 부른다.
스몰토크의 예술의 목표
본 저서의 제 2부는 스몰토크의 '예술'을 소개한다. 이는 일종의 지침서로, 적든 많든 원하는 만큼 선택하여 따를 수 있는 조언을 제공한다. 여기서는 이론적 방법론보다는 실용적 경험을 강조한다. 정밀한 방법론이 필요 없다는 말은 아니다-물론 필요하며, 특히 크고 복잡한 프로젝트에서 더 그러하다. 하지만 방법론이 반드시 스몰토크의 예술에 기반을 형성하는 '상식'이나 실제적 경험을 대체하는 것은 아니다.
본문에 제공된 조언 중 일부는 아마 모든 객체 지향 언어에 (그렇지 않다면 모든 프로그래밍에) 걸쳐 일반적으로 적용 가능할 것이다. 허나 본 저서는 스몰토크에 관한 책이며, 독자는 스몰토크에서 최대한 효과적인 방법에 가장 관심이 있을 것이기 때문에 책에 실린 대부분의 조언은 구체적으로 스몰토크 언어의 맥락으로 표현된다. 따라서 독자는 제 1부를 통해 또는 기존에 스몰토크 경험을 통해 스몰토크와 OOP 개념을 어느 정도 읽고 지식을 겸비한 것으로 가정한다.
스몰토크의 예술의 구조
스몰토크의 예술을 몇 가지로 나누고자 한다. 사실 우리는 아래 다이어그램에서 간략하게 표시된 개발 주기를 따를 것이다. 물론 이것은 일반적인 개발 주기이며, 다른 곳에서와 마찬가지로 스몰토크에도 적용 가능하다. 유일하게 다른 점은 루프를 얼마나 빠르게 돌아다닐 수 있는지가 된다. 스몰토크에서는 사실 재빠르게 가로지르는 것이 가능하다. 얼마나 이 주기를 빠르게 반복하는지는 당신에게 달려 있다-몇 분, 며칠, 몇 주, 몇 개월, 심지어 몇 개월까지 가능하다. 하지만 이 주기에 따라 활동을 분류할 수 있음을 깨달을 것이다.
처음으로 살펴볼 내용은 스몰토크의 디자인이다. 다른 것들과 마찬가지로 이와 관련해서 옳고 그름이 꼭 필요한 것이 아니다. 따라서 우리는 가장 까다로운 00 업무-'객체 찾기'- 를 생각하도록 도와주는 원칙과 개념을 고려할 것이다. 또한 좀 더 재사용 가능한 클래스를 만들도록 도와주는 다양한 방법들을 다룰 것이다.
디자인의 가장 중요한 측면들 중 하나는 상속 개념이므로, 이를 좀 더 심도 있게 고려할 것이다. 스몰토크에서는 올바르지 않은 일에 상속을 사용하기 쉽지만, 바라건대 다양한 함정을 인식하고 나면 피할 수 있을 것이다.
이제 코드의 관리를 수월하게 하고 더 재사용 가능하게 만들어줄 규칙의 이용과 스몰토크에서 코딩을 살펴볼 것이다. 그리고 최대의 효율성을 위해 스몰토크 개발 환경의 사용을 살펴볼 것이다. 최소한의 기능 집합만 사용하기란 너무나 쉽기 때문에 이번 장에선 그러한 습관을 깨고자 한다!
자신의 모든 프로그램이 처음부터 작동할 가능성은 낮으므로 다음으로는 스몰토크 자체에서 예술에 해당하는 디버깅을 살펴볼 것이다. 스몰토크에서 계속해서 나타나거나 찾기가 유난히 어려워 피할수록 좋은 버그의 전체 범위도 논할 것이다.
마지막으로는 스몰토크 개발 프로젝트의 관리 시 발생하는 중요한 문제를 몇 가지 다루고, 스몰토크 개발자 팀에서 작업하는 방법을 살펴본 후, 본 저서의 메시지를 전체적으로 요약하고자 한다.
여기서 다루지 않는 영역 중에 요구조건 분석(requirements analysis)이 있다. 재래식 프로그래밍에서와 마찬가지로 문제를 해결하기 위한 시스템을 디자인하기 전에는 문제를 잘 이해해야만 한다. 스몰토크는 해야 할 일을 안 해도 되게끔 만들어주진 않는다. 유일한 사실은 아마 스몰토크에서는 시스템 개발 속도를 통해 당신이 틀린 문제를 해결하고 있음을 초기에 발견하도록 해준다는 점일 것이다. 마찬가지로 개발 프로세스의 반복적 특성은 당신이 해결 중인 문제를 중간에 변경할 수 있도록 해준다. 하지만 재래식 프로그래밍에서와 마찬가지로 이러한 기능들조차 특정 시간에 당신이 무엇을 시도하는지 알아야 한다는 필요성을 무효화시키진 않는다.
애석하게도 스몰토크의 예술은 스몰토크의 과학에 비해 더 까다로울지 모른다. 자신만이 무엇을 시도하고 있는지를 정확히 알고 있으므로, 본문에 제시된 조언이 자신의 상황에 적용 가능한지, 그리고 적용할 것인지 결정을 내릴 수 있는 사람도 자신뿐이다. 하지만 숙련된 프로그래머라면 여기서 위안을 얻을지도 모른다. 기존에 있는 자신의 디자인과 프로그래밍 기술을 일반적으로는 객체 지향 프로그래밍, 그 중에서 스몰토크 프로그래밍으로 연결하는 방법을 알고 나면 많은 그 중 다수를 재사용할 수 있음을 발견할 것이다.
앞서 언급한 대로 스몰토크에서 디자인하고 프로그래밍하는 데에 있어 하나의 '옳은' 방식은 존재하지 않는다. 잘 작동하는 방법이 있다면 무슨 수를 써서라도 사용하라. 본문에 제시된 내용은 한 개발자의 실제적 경험 집합에 불과하다. 이를 읽고 이해하면 학습 곡선을 재빠르게 올라가도록 돕고 자신만의 스몰토크 경험을 개발시키도록 도와줄 것이다. 이제 스몰토크를 위한 디자인하기의 예술을 먼저 살펴보겠다.