TheArtandScienceofSmalltalk:Chapter 16
- 제 16 장 스몰토크 프로젝트 관리하기
스몰토크 프로젝트 관리하기
제 1장에서는 스몰토크에서 어떻게 시작하는지를 살펴본 바 있다. 이에 더해 스몰토크가 다른 언어들과 어떻게 다른지와 그 차이가 야기할 수 있는 문화적 충격에 대해 이야기했다. 뿐만 아니라 일반적인 스몰토크 '불쾌 곡선(discomfort curve)'를 살펴보고, 그 높이와 길이를 감소시킬 수 있는 다양한 방법들을 언급했다.
마지막 장에서는 스몰토크가 야기할 수 있는 관리 문제들을 몇 가지 살펴볼 것이다. 다른 많은 주제들과 마찬가지로 해당 주제를 집중적으로 다룬다 치면 한 권의 책이 필요할 만큼 복잡하므로 간략하게 살펴보겠다.
우선 소프트웨어 생명주기를 살펴보고, 훈련에 대해 언급하며, 팀을 어떻게 조직해야 할 것인지 고려해볼 것이다. 그리고 설정 관리의 기술적 문제, 매트릭스(metrics)와 측정을 살펴볼 것이다. 마지막으로는 스몰토크의 예술과 과학이 주는 기본 메시지를 상기시키면서 마무리하고자 한다.
소프트웨어 생명주기
자신의 상황에 따라 소프트웨어 생명주기에 대해 대략적으로 인식하고 있을 것이다. 하지만 개발자나 관리자들과 같은 사람들이 스몰토크에 관해 인정해야 하는 것들 중 하나는 스몰토크의 생명주기가 다르다는 점이다. 앞서 언급한 바와 같이 스몰토크는 다른 많은 언어들보다 훨씬 더 상호작용적이고 탐구적인 프로그래밍 스타일을 고취하여 안전하게 지원한다. 스몰토크가 제공하는 혜택을 얻으려면 이러한 새로운 생명주기에 적응할 필요가 있다. 좀 더 적은 자원으로 빠른 개발을 통한 혜택이야말로 애초에 스몰토크로 전향을 결정한 이유일 것이다. 새로운 환경에 맞추기 위해 자신의 작업 방식을 적응시키지 못하는 경우, 스몰토크가 제공하는 혜택을 모두 (또는 어떤 혜택도) 얻지 못할지도 모른다.
해야 할 중요한 일은 빠른 프로토타입을 생성하고 그것을 반복적으로 조정하는 자신의 능력을 활용하는 것이다. 다른 언어에서는 무언가를 코딩하는 데 소요되는 시간과, 그것이 옳지 않을 경우 수정하는 데 소요되는 시간과 관련해 매우 신중해야 했을 것이다. 스몰토크에서는 이것이 문제가 되지 않는다.
명백히 요구되는 상황에 있지 않는 한 (애초에 스몰토크의 사용에 대해 주의 깊게 생각하길 원하는 경우), 자신의 시스템 구성을 시작하기 전에 시스템을 과도하게 분석하거나 과도하게 디자인하지 말길 바란다. 최대한으로 재사용하려는 클래스 라이브러리의 '결'을 기억하라. 초기에는 탐구를 하라. 자신의 의견을 시험해보고 디자인을 향상시키기 위해 자신이 발견한 것을 사용해보라. 무엇보다 '폭포수' 방법론을 채택하려 하지 마라.
그렇다고 미친 듯이 열중하지는 마라. 스몰토크는 난투전에 대한 변명이 될 수 없다. 상호작용적 생명주기(interactive lifecycle)는 시스템에 대한 수정이 추가되면서 코드량을 증가시키는 결과를 야기한다. 프로세스에 시간을 할당하여 주기적으로 되돌아가 이미 작성한 코드를 정리하고, 중복 메서드나 변수를 제거하며, 가능할 때마다 그것을 일반화시키도록 하라.
스몰토크에서 개발을 시작하기로 결정을 내렸다면 아마 가장 먼저 고려하는 사항들 중 하나가 바로 훈련일 것이다. 제공 받는 훈련의 비용에 대한 가치나 질은 당신만이 판단할 수 있는 문제지만, 시작하게 될 훈련의 유형에 대해 결정을 내리도록 도와줄 수 있는 일반 지침들이 몇 가지 존재한다.
첫째, 구체적으로 스몰토크 훈련인지 확인하라. 일반 객체 지향 디자인과 프로그래밍 과정도 존재한다. 이러한 훈련도 괜찮지만 스몰토크에 한정된 훈련을 대체할 수는 없다. 개발자들을 C++ 과정으로 보내거나, 이전에 그런 과정을 밟아봤으니 스몰토크도 이해할 것이라는 생각의 함정에 빠지지 않길 바란다. 사실이 아니기 때문이다. 뿐만 아니라 대화형 개발 시스템에서 (예: VisualBasic ) 스몰토크로 전향하는 것은 사소한 일이 아니라는 사실을 인식하라. 복잡성의 증가는 꽤 충격적일 수 있다!
둘째, 때로는 개발 팀의 몇몇 구성원에게 집중 훈련을 제공하고 그들이 나머지 구성원을 훈련시키도록 하는 과정을 시도해볼만하다. 사람들은 실습을 통해 스몰토크를 가장 잘 학습하지만 자신보다 경험이 조금이라도 많은 사람을 쉽게 이용할 수 있다면 그 가치는 엄청나게 크다. 마지막으로 객체와 스몰토크로의 전향은 재량이 손실될 것만 같은 엄청난 두려움을 야기하기도 한다. COBOL 또는 MS-Windows 프로그래밍 전문가로 알려진 사람들은 초보자 수준으로 작아지는 자신의 모습을 발견할 것이다. 아니면 초보자 수준으로 줄어든 것처럼 느낄 것이다. 하지만 열린 마음을 갖고 새로운 패러다임을 탐구할 시간이 주어지면 똑같은 수준의 재량을 재빨리 회복할 수 있을 것이다.
팀 구성하기
스몰토크가 장려하는 다른 생명주기, 그 프로그램과 시스템에서 발견할 수 있는 다른 아키텍처 또한 개발 팀의 구성 방식에 영향을 미친다. 당신은 이러한 차이들을 인식하고 있어야 한다.
스몰토크의 반복적 생명주기를 이용하기 위해서는 아마도 분석가, 디자이너, 프로그래머의 업무를 결합해야 할 것이다. 앞서 관찰하였듯, 추상적으로 스몰토크를 위한 디자인은 까다롭다. 객체와 메서드를 명시하기 전에 재사용 가능한 클래스로는 어떤 유형이 있는지 알 필요가 있다. 스몰토크가 아니어도 스몰토크 클래스의 디자인을 전달하기가 까다로운데 뭐하러 그런 수고를 해야 할까? 핵심은 팀의 모든 사람이 개발 중인 애플리케이션을 인식할 필요가 있다는 점과, 분석가, 디자이너, 프로그래머의 역할을 필요 시 수행할 수 있어야 한다는 점이다. 이와 같이, 팀의 모든 인원은 스몰토크에 대략적으로 익숙할 필요가 있으며, 목표 언어에 대해 아무 것도 모르는 분석가나 디자이너라면 소용이 없다.
재래식 프로그래밍에서와 마찬가지로 코드의 생성자와 소비자가 있다. 스몰토크에서 프로그래머들 간 전송 단위는 클래스인 경향이 있다. 개개인들은 그들이 디자인하고 빌드한 클래스, 즉 다른 사람들이 캡슐화 또는 상속을 통해 재사용하도록 만든 클래스를 소유할 것이다. 클래스들 간 인터페이스는 전과 마찬가지로 분명히 정의되어야 한다. 하지만 스몰토크에서는 모듈 간 APIs(애플리케이션 프로그램 인터페이스)에 대해 이야기하지 않고 오히려 서로 다른 클래스들이 지원하는 프로토콜에 대해 이야기하는 경향이 있다.
클래스들 중 다른 것들에 비해 더 재사용이 가능한 클래스가 있는 것이 보통이다. 이러한 클래스들이 애플리케이션에 특정적이지 않을 경우, 나머지 애플리케이션 부분이 빌드된 프레임워크를 형성하는 경향이 있다. 이러한 점을 반영하기 위해 당신은 프레임워크 개발자와 애플리케이션 개발자를 고려하여 개발 팀을 구성하길 원할지도 모른다. 이러한 과정을 잘 수행한다면 많은 애플리케이션에 걸쳐 재사용이 가능한 프레임워크를 만들어낼 것이다. 재사용은 팀 관리에 영향을 미치는 또 다른 요인이다. 모든 사람에게선 타인이 만든 코드보다 자신의 코드를 더 신뢰하는 (최소한 더 잘 이해하는) 경향이 크게 나타난다. 이러한 경향이 자연스레 사람들 간 코드 재사용에 불리하게 작용한다. 이를 조정하는 방법에는 최소 두 가지가 있다.
첫째, 재사용에 이용 가능한 것에 대한 지식을 증가시켜라. 재사용 가능한 코드의 '라이브러리'의 준비를 시도해보라. 특정 팀 구성원이 사서의 역할을 맡아 이러한 클래스의 사용을 관리하고 장려할 것을 권한다. 둘째, 가치가 있는 재사용을 분명하게 고려하라. 재사용을 어떻게 측정하는지는 또 다른 문제지만 (후에 살펴볼 것이다), 프로그래머가 작성하는 코드 행의 수로 그를 평가하고 있다면 광범위한 재사용을 장려하는 데 도움이 되지 않는다.
설정 관리
다른 언어나 개발 환경에 비교할 때 스몰토크의 가장 취약한 영역들 중 하나가 바로 설정 관리의 지원이다. 프로그래머 혼자서 애플리케이션의 한 가지 버전을 개발하기엔 훌륭한 시스템이다. 하지만 여러 명의 프로그래머가 애플리케이션의 여러 버전을 개발하기 위해 협력하여 일하는 경우, 스몰토크는 뭔가 부족한 감이 없지 않아 있다.
이러한 장애를 극복하기 위해 VisualWorks 환경을 향상시킬 수 있는 상업용 패키지가 있다. 그 중 하나는 (Object Technology International의 ENVY/Manager) 매우 유명하며, (프로그래머의 수가 다섯 명 이상인) 대규모 프로젝트에서 필수 패키지로 많이 간주된다. 하지만 코드 관리 패키지에 투자하지 않고도 자신에게 도움이 되는 단계들이 많다.
첫째, 스몰토크의 'save-image'와 'file-out' 메커니즘을 코드의 저장 방법과 공유 방법으로 구별하라. 이미지는 프로그래머에게 private한 것이어야 한다. 이미지는 당신의 모든 비트와 조각, 클래스와 인스턴스, 전역 변수를 비롯해 개발 과정에서 작업대에 필요한 모든 것을 포함할 것이다. 이는 매우 강력한 기능이며, 앞서 언급한 바와 같이 이미지를 시시때때로 저장하여 30분 정도마다 작업의 스냅숏을 만드는 일반적인 방법으로 이용해야 한다.
하지만 다른 사람과 당신의 이미지를 공유해서는 안 된다. 다른 개발자에게 코드를 전송하고 싶다면 코드를 파일로 작성하는 file-out 메커니즘을 이용해 다른 사람이 그 코드를 자신만의 이미지로 file-out하도록 해야 한다. 이러한 코드 공유 방식도 개개인의 프로그래머가 소유한 코드 단위의 특성에 영향을 미친다. 전체 카테고리, 전체 클래스, 전체 프로토콜, 또는 각 메서드를 file-out할 수도 있다. 따라서 이러한 것들은 모두 팀의 구성원들에 대해 적절한 소유(ownership) 단위가 된다. 한 명의 팀 구성원이 다른 구성원의 클래스에서 세 가지 다른 프로토콜 내의 메서드 다섯 개를 소유하는 것이 훨씬 더 까다롭다.
두 가지 저장 메커니즘을 (save-image와 file-out) 적절하게 분할한 코드 소유권과 결합하여 기본 설정 관리 과정을 만들 수도 있다. 이러한 과정은 약간의 책임감과 관심을 이용해 다음과 같이 수동으로 관리할 수 있다:
기반(base) 스몰토크 이미지로 시작하라. 굳이 개봉 시 제공되는 이미지일 필요는 없다. 이 이미지는 당신이 생각하는 수정이 무엇이든 당신의 개발 환경에 전적으로 기본적으로 만들 수 있다-최소한 표준 시간대는 올바로 설정하라!
작업을 분할하여 각 프로그래머가 가급적이면 클래스의 전체 카테고리를 소유하도록 하라. 때로는 공유 카테고리 내 각 클래스를 소유해야 하기도 하고, 때로는 심지어 각 프로토콜과 메서드까지 소유해야 하는 경우도 있다. 이 모든 것은 수용 가능하지만 명확하게 나눌수록 프로세스가 더 잘 작동할 것이다.
공유 파일시스템(LanManager, Novell, NFS 등)을 이용해 이러한 카테고리, 클래스, 프로토콜, 메서드의 file-out을 보관할 디렉터리 구조를 결정하라. 퍼미션(permissions)을 설정하여 소유자만 해당 디렉터리를 읽고 작성할 수 있지만 소유자를 제외한 사람은 읽기만 가능하도록 하라.
이제 프로그래머가 코드 단위를 생성하거나 수정하여 배포하길 원할 때마다 그(녀)는 그 단위를 공유 파일공간으로 file-out해야 한다. 매일 (혹은 상황에 따라 자주) 각 프로그래머는 기반 이미지로 시작하여, 공유 파일공간으로부터 모든 추가(additions)내용을 file-in해야 한다. 이는 프로그래머가 낮 동안 작업하는 시스템을 최신 버전으로 빌드한다. 개개인의 프로그래머는 무언가 진행되었다고 느낄 때마다 자신의 이미지를 개인적으로 저장해야 하지만 코드를 배포할 준비가 되었을 때는 공유 영역으로 file-out해야 한다.
위와 같은 간단한 형식은 모든 개개인의 개발 단계가 뒤쳐지지 않도록 해주는 동시 이미지가 너무 오래 지속되는 (long-lived) 것을 방지한다. 하나의 이미지를 몇 주에서 몇 개월씩 사용하여 개발하는 것은 좋지 못한 생각이다. 개발 과정에서 일어나는 부가적 효과로서 수많은 전역 변수와 쓰레기가 축적되어 이미지가 '피곤해'지고 취약해지는 경향이 있다. 이러한 결함을 프로그래머들끼리 공유하는 것은 바람직하지 못하다.
이렇게 완전히 수동적인 계획을 향상시킬 수 있는 방법에도 여러 가지가 있다. changes 로그를 이용하면 시스템의 어떤 부분이 수정되었는지 말해주는 것이 가능하다. 따라서 요구 시 어떤 부분을 file-out할 것인지 알고 있는 코드를 빌드하는 것이 가능하다.
Boot-strap loader와 같은 유형의 클래스를 빌드하는 것도 좋은 생각이다. 해당 클래스는 (C makefile과 동등) 이미지를 빌드하기 위해 file-in 되어야 하는 다른 모든 파일에 대해 알 수 있다. 해당 클래스를 작성하면, 단순히 file-in하여 그 곳으로 load와 같은 메시지를 전송함으로써 나머지 시스템을 모두 file-in할 수 있다.
마지막으로, file-out 은 단순한 ASCII 파일이므로 자신의 시스템에서 하나 이상의 버전을 유지할 수 있으려면 다른 설정 관리 소프트웨어(예: RCS)로 관리할 수 있다는 사실을 기억하라.
매트릭스와 측정
측정할 수 없는 대상은 관리할 수 없다는 사실을 발견할 때가 종종 있다. 불행히도 스몰토크에서 프로그래밍을 할 때는 무엇을 측정해야 하는지가 결코 분명하지 않다. 이는 당신이 관리하거나 최적화하고 싶은 대상에 따라 크게 좌우되며, 자신에게 무엇이 주요한지, 그것을 어떻게 측정할 것인지, 측정한 내용에 대해 어떻게 응답할 것인지에 대한 결정은 경험을 통해서만 내릴 수 있을 것이다. 즉, 프로그래밍을 주의 깊게 제어하고 싶다면 자신만의 측정 기록을 준비하여 시간이 지나면서 그리고 상황에 따라 어떻게 변화하는지를 기록할 필요가 있다.
아래에 측정이 가능한 대상들을 몇 가지 열거해보았다. 이러한 측정 대상들 중 VisualWorks 에서 직접 지원하는 것은 없지만 다수는 약간의 재량으로 프로그래밍이 가능하다.
- 코드 행 (lines of code)
- 메서드 개수
- 클래스 개수
- 메서드별 코드 행
- 클래스별 코드 행
- 클래스별 메서드
- 재사용되는 코드 행
- 재사용되는 메서드
- 재사용되는 클래스
- 클래스별 인스턴스 변수
- 클래스별 인스턴스
- 상속 깊이
- 메서드간 응집도(cohesion)
- 클래스간 결합도
이러한 매트릭스들 중 일부는 분명 나머지에 비해 더 가치가 있다. '코드 행'은 특히 다른 프로그래밍 언어와 비교하면 아마도 가장 관련이 적을 것이다. 시간당 얼마나 많은 코드 행을 작성할 수 있는지를 비교하여 다른 언어에서 당신의 효율성을 스몰토크에서의 효율성과 비교할 수는 없는 노릇이다. '메서드 개수'와 '클래스 개수'는 확실히 당신의 시스템이 얼마나 큰지, 당신이 얼마나 빠르게 작성하는지를 측정하는 데 더 나은 측정치가 된다.
'메서드별 코드 행'은, 너무 긴 메서드가 (10줄 이상) 나타날 것이기 때문에 아마도 훌륭한 측정치가 될 것이다. '클래스별 메서드'는 그 흥미도가 좀 떨어지지만 '메서드간 응집도'(메서드들이 동일한 인스턴스 변수 집합에서 실행되는지 여부)는 아마 두 개 혹은 그 이상의 분리(disjoint) 요구를 충족하는 클래스를 표시할 것이다.
'재사용되는 메서드와 클래스'는 (상속과 캡슐화 둘 중에 하나를 통해-두 가지 모두 측정 방법을 기억해야 한다) 재사용을 장려하고자 한다면 훌륭한 측정치가 된다. 다른 클래스로부터 상속되는 클래스를 조심하고, 해당 클래스로부터 많은 기능을 사용하지 않도록 하라. 부적절한 상속을 나타낼지도 모른다.
'상속 깊이'는 너무 얕거나 (클래스간 공통성을 인지하지 못할 가능성을 암시) 너무 깊을 수 (부적절한 상속으로 불필요한 복잡성으로 이어짐) 있기 때문에 미묘한 측정치이다. '클래스간 결합도'는 특정 클래스 집단에서 얼마나 많은 인스턴스가 서로 상호작용하는 경향이 있는지를 측정한다. 이는 한 클래스의 구현부를 다른 클래스가 너무 의존하고 있음을 나타내기도 한다.
요약 및 최종 결론
본장에서는 재래식 언어로부터 스몰토크 개발로 전향 시 수반되는 일부 사람들, 프로젝트, 변화 관리 문제를 매우 간략하게 살펴보았다. 다른 많은 서적을 비롯해 본문을 통해 전하는 가장 중요한 메시지는 바로 스몰토크가 다르다는 점이다.
단순히 기존에 있는 프로세스를 지속하면서 OOP, 상호작용적 개발, 스몰토크의 혜택을 실현하도록 기대할 수는 없다. 최소한 어느 정도의 재훈련, 개발자들에게 필요한 기술 조합의 변화, 극심한 불편함의 기간을 거칠 준비가 되어 있어야 한다. 하지만 본 저서에서 여기까지 읽을 만큼 버텼다면 이러한 변화를 시작할 준비가 된 것이며, 그러한 헤택을 보기 시작하면 헤택을 실현할 수 있을 것이다.
본장은 또한 스몰토크의 예술과 과학의 마무리를 짓는 장이므로 우리가 고려한 중요한 내용을 되돌아볼 시간이다.
가장 중요한 가르침은, 약간의 지식이 오래 지속될 수 있다는 점이다. 스몰토크 개발자들이 알아야 하는 핵심은 시스템을 탐구하는 방법이다. 훌륭한 스몰토커들은 모든 것을 다 아는 것이 아니라 그들이 원하는 내용을 어떻게 찾는지 아는 사람들이다. 이러한 탐구적 과정을 촉진시키고 지원하기 위한 몇 가지 툴을 VisualWorks 환경에서 어떻게 사용하는지 자세히 살펴보았다.
이러한 탐구적 재능은 시스템 클래스 라이브러리 내 공통 클래스에 관해, 그리고 그 클래스들이 어떻게 구조화되고 사용되는지에 대한 기본 지식과 결합될 필요가 있다. 우리는 공통된 클래스를 몇 가지 살펴보고, 그들의 디자인을 제어하는 명명 규칙과 코딩 스타일도 논한 바 있다. 뿐만 아니라 이러한 스타일에 일치하는 방식으로 시스템을 확장하는 방법도 (스몰토크에서 프로그래밍을 하는 의미이므로) 고려해보았다.
마지막으로, 스몰토크와 다른 재래식 언어들 간 차이가 어떻게 소프트웨어 개발 과정을 변경하는지도 살펴보았다. 특히 우리는 스몰토크 개발은 독자가 익숙해하는 과정에 비해 훨씬 더 반복적이고 상호작용적인 과정이라는 사실을 관찰했다. 무엇보다 이 모든 차이를 세심하게 고려하면 스몰토크에 투자해서 돌아오는 이익을 최대화할 수 있을 것이다.