SmalltalkObjectsandDesign:Chapter 21

제 21 장 소프트웨어 개발이 여전히 어려운 이유

소프트웨어 개발이 여전히 어려운 이유

소프트웨어 개발은 여전히 어려운 작업이다. 모든 측면이 힘들다: 요구 조건을 이해시키는 일, 훌륭한 클래스를 디자인하는 일, 일관된 사용자 인터페이스를 빌드하는 일, 확장 가능한 코드를 작성하는 일. 객체는 기업에 흥미로운 특징을 추가하지만 객체 지향 개발의 노력이 그 목표를 성취하지 못하는 일이 종종 발생하고, 그 중 많은 개발은 순전히 실패로 끝난다. 대체 뭐가 문제일까?

오해

객체 지향 소프트웨어 개발은 많은 사람들이 기대하는 장미로 덮힌 침실이 아니다. 이번 장에서는 그 중에서 많이 알려진 오해를 어느 정도 살펴볼 것이며, 당신의 기대치를 현실적인 수준으로 맞춰놓을 것이다.

객체 지향 개발은 학습과 실행이 쉽다

현실: 스몰토크 언어는 너무나 작기 때문에 학습하기가 쉽다. 하지만 언어 자체는 그다지 많은 일을 하지 않는다. 언어가 강력해지는 원인은 오늘날 스몰토크 제품에 속하는 수백 개의 기본 클래스와 수천 개의 지원 클래스와의 협력 때문이다. 깔끔한 스몰토크 코드를 작성하려면 그 전에 이러한 클래스 중 다수를 학습해야 할 것이다. 이러한 학습에는 시간과 연습이 필요하다.

이 책에 실린 개념의 적용에 익숙해지는 데에도 시간이 소요된다-컨테이너, 다형성, 패턴 등으로 디자인하기. 모두들 객체를 이해하고 그것에 관해 이야기하는 선천적 능력은 있으나 훌륭한 디자이너가 될 수 있도록 오래 열심히 작업하는 사람은 많지 않다. 이렇게 생각해보자: 객체 지향 개발은 기법으로 이루어진 툴킷을 증대시켜 결국 엉망으로 만들 기회가 더 많아진다. 경험에 따라오는 성숙도가 없다면 확대된 가능성의 세계에서 바람직한 해답을 정확히 찾기가 여느 때보다 힘들다.

경험이 부족한 프로그래머가 객체를 더 잘 다룬다

객체 지향 프로그래밍, 특히 스몰토크 프로그래밍에 관해 흔히 가진 오해는 관습적 프로그래밍 경험은 나쁜 습관도 같이 학습할 것이기 때문에 해가 될 것이라는 점이다. 이러한 오해의 극단적 형태는, 재래식 프로그래밍 언어로 인해 타락하느니 프로그래밍을 전혀 해보지 않은 것이 낫다는 주장이다. 따라서 이 주장은 객체 지향 프로젝트가 경험이 있는 프로그래머보다는 경험이 없는 미숙한 프로그래머가 관여 시 더 성공할 수 있다는 주장이다.

현실: 증거는 정 반대를 제시한다. 프로그래밍의 경험은 객체 지향성을 학습하는 데에 이득이 된다. 그리고 계획을 예정대로 진행하고 그 이정표를 충족하여 사용자와 관리자를 만족시키는 프로젝트들은 지식이 많은 프로그래머들의 작품이다-전문가가 많을수록 좋다. 전문 프로그래머들은 소프트웨어 개발의 전체적 기반 시설-연결성, 데이터베이스, 버저닝과 구성 관리, 검사, 절차적 로직, 요구조건 수집-에 뛰어난데, 이 사항들은 모두 객체가 유행하기 전, 즉 어떤 것도 객체로 인해 진부해지기 이전에 소프트웨어 개발에 필수적인 항목들이었다. 그리고 전문가 프로그래머는 객체를 더 빨리 학습하고, 그 영향을 인식하며, 현재 문제에 어떻게 적용하는지를 잘 감지한다.

객체 지향 프로젝트는 더 성공적이다

현실: 객체 지향 프로젝트라고 해서 다른 프로젝트보다 성공할 가능성이 높은 것은 아니다. 현실을 반영하지 않는 리더십, 잘못된 낙관론, 현 상태에 대한 안주, 올바르지 않은 툴, 그 외의 모든 것이 다른 프로젝트만큼이나 객체 지향 프로젝트를 괴롭힌다. 성공적인 프로젝트는 기술적 노하우가 결합된 뛰어난 사업 감각을 필요로 하며, 이러한 기능들은 객체 지향 프로젝트뿐만 아니라 전형적인 프로젝트에서도 찾을 수 있다.

객체 지향 애플리케이션은 재사용을 즐긴다

현실: 프로젝트는 일관된 프레임워크가 제자리에 있을 때 재사용을 즐긴다. 프레임워크의 추상적 클래스는 개발자들이 중복성을 피하도록 돕는다. 하지만 프레임워크는 빌드하기가 힘들며, 특히 프레임워크가 다루어야 하는 첫 번째 문제와 관련해 더 그렇다. 따라서 하나의 프로젝트 내에서 재사용이 자동적으로 따라오는 것은 아니다.

프로젝트 간에 객체의 재사용 또한 마찬가지다. 플러그 호환 가능한 객체들은 드물다. 소프트웨어 개발의 압력을 받으면서 제품의 설계 의도와 다른 객체는 고사하고 설계 의도에 맞게 작동할 객체를 만드는 것은 충분히 힘든 일이다. 처음으로 빌드하는 당사자는 나중에 비를 맞으면서 빌드하게 될 것을 염려하지 않는다. 그러면서 모든 주의를 요구한다.

프로젝트들 간에 재사용이 발생할 때는 다른 프로젝트에서 성공적인 프레임워크 형태로 이루어지는 것이 일반적이다. 훌륭한 프레임워크의 추상 클래스에는 다중 프로젝트로 적용할 수 있는 가능성이 있다. 마침내 우리는 구체적 클래스의 기업 또는 산업용 라이브러리를 수집하는 데에 성공할 것이지만 우리가 완전히 이해하는 문제-오래된 문제-에 한해서만 적용된다. 한편 가장 재사용이 가능한 자원은 자신의 디자인일 것이다: 코드 자체보다는 코드가 생성되었다는 자체가 중요하다. 이 책의 어휘집에 제시하였듯이 조직의 실제적 자산은 사람들이 보유한 패턴과 객체에 대한 개념적 모델이다. 따라서 애초에 조직은 코드보다는 사람과 함께하는 편이 나을 것이다.

성능은 언어에 의존한다

현실: 성능은 일반적으로 프로그래밍 언어의 결과로 간주한다: 어셈블러와 C++는 빠르다; 반대로 LISP와 Smalltalk 는 느리다. 하지만 프로그래밍 언어가 성능에 미치는 효과는 디자인의 효과보단 덜하다. 훌륭한 스몰토크 디자인은 불량한 C++ 디자인보다 빠르고, 그 반대도 마찬가지다. 따라서 디자인은 언어보다 더 중요하다.

분산 객체의 성능을 특히 조심하라. 이들은 일반적으로 스몰토크 또는 C++ 환경 중 한 곳에서 작동하기에 충분히 이식이 가능한 일반적인 객체들이다. 우리는 그러한 객체 중 하나의 성능이 네이티브 스몰토크의 객체 성능에 비해 70배 정도 느린 것으로 측정하였다. 극단적 일반성이 항상 그렇듯 이 또한 매력적인 만큼 치뤄야 할 대가가 크다.

데모가능(Demo-able)하다면 실행가능(do-able)하다

현실: 데모는 빙산의 일각에 불과하다. 힘들고 시간이 많이 소요되는 작업은 이후에 데모부터 시작되는데, 강력하고 빠른 분산 또는 클라이언트/서버 지원을 생성 시 발생한다. 객체가 네트워크에 걸쳐 지속되도록 만드는 일은 까다롭다. (경계의 문제는 267 페이지를 참고한다.) 여기 경험에 따른 규칙이 하나 있다: 로컬 데이터베이스에서 실제 데이터의 접근 예제를 포함해 소프트웨어가 완전히 작동하는 순간부터는 최종 산물을 내놓는 데에 들이는 수고의 절반만큼을 허용하라. 다시 말해, 사용자에게 최종 산물로 나타나는 완전한 운용 조건의 발매(fully operational requirements release)는 전체 노력의 40%만 차지한다. 최종 산물을 기다리는 모든 사람이 이 메시지를 받는 것이 중요한데, 그렇지 않을 시 후원자를 실망시킬 위험을 감수해야 할 것이다. 그들이 만지고 볼 수 있는 것은 개발 주기 대부분에 걸쳐 변경되지 않는다.

GUI 빌더는 수월하게 만든다

현실: GUI 빌더들은 지루함을 완화한다. 그들은 소프트웨어 툴에 즐거운 첨가물이다. 하지만 모델-뷰의 구분을 자동으로 만들지는 않으며, 심히 도전적인 작업인 디자인으로부터 우리의 주의를 돌린다. (제 13장을 기억하라.)

"나는 스몰토크로 디자인한다"

현실: 스몰토크 프로그래밍은 디자인에 매우 가깝지만 디자인과 똑같진 않다. 블랙보드, 화이트보드, CRC 카드, 또는 컴퓨터에서 떨어져 어디선가 작업하고 있다면 분명히 디자인을 하고 있는 것이다. 훌륭한 디자인은 종종 사회적 활동에서 발생한다. 그리고 까다로운 디자인 문제는 당신이 누군가에게 그 어려움을 설명하고자 시도하면 굴복하게 되어 있고, 어떤 하찮은 말 한 마디가 그 문제를 해결할 수 있는 의견이 되기도 한다.

그럼에도 불구하고 스몰토크 시스템 앞에서 보내는 시간의 대부분은 순수히 디자인을 위한 시간이다. 디자인은 대안책들을 이리저리 따져 보는 단계로, 첫 발견부터 최종적으로 하나만 남기고 제외시키는 작업을 모두 포함한다. 이는 클래스를 조사하거나 (오늘날 스몰토크는 수천 개의 클래스를 포함함을 기억하라), 그들의 메서드를 읽고 실험하거나, 자신만의 일회용 클래스와 메서드를 생성할 때 하는 일이다. 클래스와 선택자의 이름을 명명하거나 주석을 무어라 써야 할지 고민하는 과정도 해당된다. 스몰토크로 작업하는 일은 디자인의 형태긴 하나 유일한 형태는 아니다.

프로젝트가 실패하는 곳: 경계

개발 팀이 자신들의 애플리케이션을 다른 중요한 컴퓨팅 시스템으로 연결하는 데에 발생하는 어려움을 과소평가하면 극적인 프로젝트 오버런이 발생한다. 이러한 시스템은 사실상 기업용 표준인 홈 그로운(home grown) 시스템이거나 기성품(off-the-shelf) 데이터베이스 제품일지도 모른다. 스몰토크 애플리케이션과 이러한 시스템 사이의 경계를 뛰어넘기 위해서는 신중한 디자인이 요구된다. 스몰토크 객체는 각 경계의 한쪽에 위치하고, 반대편에는 그러한 객체와는 다른 무언가가 위치한다. 개발 팀이 이러한 불일치를 해결하기 위해 시간 또는 재능은 투자하는 경우는 드물다.

전형적인 시스템 경계는 오늘날 대부분의 클라이언트/서버 애플리케이션에서 발생하는 객체와 관련된(relational-to-object) 인터페이스다. 데이터베이스 서버는 로컬 LANL에 위치할 수 있지만, 원격 또는 메인프레임 컴퓨터에 위치할 경우 경계를 건너는 데에 가능한 기법의 수는 몇 배로 상당히 증가한다. 트래픽의 흐름이나 크기를 처리할 수 없는 해결책, 혹은 구현하기에 비용이 너무 많이 드는 해결책, 또는 시험하기가 힘든 해결책을 선택할 경우에는 경험이 많은 개발자들이 필요하다. 깔끔하고 효율적인 해석은 경계의 양쪽에 모두 익숙할 때에 발생한다.

다른 종류의 "서버"가 그림에 들어오면 장애는 빠르게 확산된다. 언젠가 필자가 작업한 프로젝트들의 요구사항에 다른 기업 시스템-급여 시스템, 세계적 고객 데이터베이스, 오버플로우 시스템 등-들과의 경계가 포함된 적이 있다. 이러한 경계는 아래와 같은 이유로 위험하다:

• 다른 시스템이 아직 작동하지 않는다.
• 다른 시스템이 우리의 새로운 고객 애플리케이션과 인터페이스를 갖도록 설계되지 않았다.
• 인터페이스가 존재하지만 우리 고객의 요청을 처리하기 위해 다른 시스템에 새로운 프로그램이 작성되어야 한다.
• 시스템이 다른 언어로 작성되었기 때문에 완전히 다른 조직에게 작업을 위임해야 한다.
• 다른 시스템으로의 물리적 연결을 신뢰할 수 없다.
• 경계를 건너는 시험의 비용이 엄청나게 증가한다.

시스템 경계에서 조그마한 실패가 발생하면 애플리케이션 cold가 중단된다; 이러한 유형의 실패는 사용자 인터페이스나 모델 객체에 발생하는 버그보다 더 치명적이고 비용이 많이 든다. 숙련된 프로젝트 기획자들은 프로젝트 자원의 절반 이상을 (60퍼센트-266페이지 참고) 경계 문제에 할당한다. 즉각 이용이 가능한(turnkey) 블랙박스 해결책이 당신의 문제와 일치하는 경우는 드물며, 적응하기도 힘들다. 작업 가능한 해결책은 한 편에 프레임워크를, 반대편에는 가령 외국어를 수반한다.

시스템 경계는 가장 극적인 장애점이 될 수 있지만 모든 경계는 실책의 기회가 된다. 제 13장은 위험한한 인간-컴퓨터 경계에 관련된다. 그 경계는 관습적으로 요구사항 수집(requirements gathering)이라 불리는 것과 딱 들어맞는데, 이는 문제 영역의 전문가와 분석가 간 경계를 의미한다. 이 경계에서 얻은 불분명한 요구조건은 많은 실망스러운 프로젝트의 핵심에 위치한다. 하지만 소프트웨어 개발에서 모든 인간-인간 경계는 의견을 전달하는 데 대해 비효율성을 어느 정도 야기한다.

최종적으로 미세한 경계에는 프로그래밍 객체의 public 인터페이스가 해당된다. 각 객체가 public 메서드 선택자들로 구성된 이해 가능한 외부를 가져야만 사람들이 사용 방법을 알 수 있을 것이다. 이러한 객체 경계를 올바로 설정하는 것이 프로그래머의 핵심 의무이다. 각 객체에서의 가르침은 대규모 소프트웨어 개발에서의 가르침과 일치한다: 경계 또는 인터페이스가 가장 중요하다. Xerox PARC에서 스몰토크 전성기 시절 가장 저명한 사람들 중 하나인 Peter Deutsch는 아래와 같이 요약했다: "인터페이스 디자인과 기능적 팩토링(functional factoring)은 소프트웨어의 중요한 지적 내용을 구성하고, 코드에 비해 재생성이 훨씬 힘들다" [Deutsch 1991].

성공적인 프로젝트의 특징

효율적으로 경계를 넘나들기 위해서는 경계를 우선 이해해야 할 것이다. 따라서 첫 번째로 안내할 것은 가독성이다.

가독성

가끔 버그가 발생하여 코드를 자세히 들여다볼 필요가 생기면 당신은 그 즉시 객체 지향의 스파게티가 취약하게 뒤얽혀 있는 소프트웨어를 만나곤 한다. 새로운 오류를 발생시키지 않고선 소프트웨어 확장은 둘째 치고 버그를 수정할 가망도 없게 된다. 작동하는 소프트웨어는 읽는 것이 즐겁지 않은 이상 인상적일 수가 없다: 즉, 미스터리가 없어야 한다.

가독성은 보통 주석; 스타일; 메서드와 클래스와 인스턴스 변수의 이름; 등을 수반한다 ([Skublics et al. 1996] 참고). 하지만 너무나 많은 메서드에 의해 짓눌린 window 클래스, 구체화되어야 하는 복잡한 행위, 혹은 패턴이나 추상 클래스 등으로 재팩토링할 수 있는 코드 등 더 광범위한 고찰사항도 포함한다. 가독성은 훌륭한 디자인과 거의 같은 의미로, 측정 가능한 것보다는 오히려 예술에 가깝다.

분명한 코드를 작성하는 동기가 특이한 근원에서 발생할 수도 있다. 열렬하지만 경험이 없는 프레임워크 개발자가 남긴 클라이언트/서버 코드를 뒤따라 고통을 받던 하나의 프로젝트가 "The Method from Hell(지옥에서 온 메서드)"라는 컨테스트를 후원했다. 해당 프레임워크에서 가장 엉망이고 이해할 수 없는 메서드를 찾는 사람이 컨테스트의 우승자였다. 이러한 우호적 경쟁의 부산물로 개발자들은 미래의 영광을 차지할지 모르는 자신의 메서드를 작성하기 전에 두 번씩 생각하게 되었다.

코드의 샘플을 읽는 것은 사람의 온도를 측정하는 것과 같다: 복잡한 코드로 된 프로젝트는 열이 있는 사람과 같아 건강할 수가 없다. 코드는 다른 모든 요인들이 집합하는 곳이다; 읽을 수 없다면 어딘가 문제가 있는 것이다. 문제의 근원이 잘못된 분석, 대충 만든 디자인 또는 엉성한 구현, 혹은 심지어 조직적 구조나 프로세스에 있다면 즉시 문제를 알지 못할 것이다. 하지만 조사를 시작해야 한다는 사실은 알고 있을 것이다.

이름

명확한 이름은 가독성에 필수적인 요소다: 메서드명, 인스턴스 변수명, 클래스명. 클래스를 바라볼 때 스몰토크 프로그래머가 처음으로 하는 일은 클래스의 메서드 선택자들을 살펴보는 일이다. 잘 명명된 선택자들은 길잡이가 된다; 그리고 형편없이 명명된 선택자들은 프로그래머를 혼동시키고 이해를 방해한다. 나쁜 이름들은 프로젝트를 영원히 따라다닌다; 훌륭한 이름들은 소프트웨어의 디자인을 자랑스럽게 알린다.

이름은 객체 지향 소프트웨어에서 특히 중요하다. 누군가 클래스에 부여하는 이름은 해당 클래스의 특성을 다른 누군가-분석가, 개발자, 검사자-에게 즉시 그리고 분명히 떠올리도록 해주어야 한다. 효과적인 이름은 올바른 개념을 함축할 뿐만 아니라 개발자들 간 대화를 위한 손잡이 역할을 한다. 훌륭한 이름, 평범한 이름, 형편 없는 이름의 결과를 각각 소개하고자 한다:

• 어떤 개념에 붙인 별명은 개발자들 간 의사소통을 돕는다. 고스트의 클래스명으로 SkinnyCustomer를 결정한 후 (226 페이지) 인스턴스를 "skinnies"라고 불렀다. 이 별명은 잇따라 수많은 개념적 논의를 촉진시켰다.
• 정확한 이름은 일상적 사고와 대화에 너무 번잡할 수 있다. MutualFundAccountTelephoneExchangeRole은 정확히 옳을지는 모르지만 너무 길어서 뇌가 처리하는 데까지 시간이 걸린다. 때로는 간단한 이름을 위해 약간의 정밀성을 희생하고, 모두의 이해를 충족시키기 위해 프로젝트의 맥락을 신뢰하는 것도 좋겠다.
• 다른 극단적인 예로, 모호한 SmartGuy와 같은 이름을 들 수 있겠다. 이런 부적절한 이름의 설명들이 여러 사람들의 마음에 서로 다른 생각을 불러 일으킨다는 이유로 몇 주간 회의가 계속되었다. 여기서는 이름의 선택이 디자인을 향상시킨 것이 아니라 오히려 방해되었다. (이 프로젝트에서 SmartGuy의 행위는 TaskMonitor나 WorkflowServer 등의 여러 구체적인 이름으로 식별할 수 있는 생각들을 포함했다.)

형편없는 이름은 시간과 돈을 낭비한다. 우리는 그것이 의미하는 바를 재구성하는 데에 정신적 에너지를 소비한다. 프로젝트에서 노랑허리솔새(yellow-rumped warbler)를 "붉은어깨검정새"라고 명명한다면, 누군가 "붉은어깨검정새"라고 말할 때마다 우리는 본래 상상하는 작은 여자 같은 새가 머리 위를 날아다니는 모습 대신 갈대에 있는 땅달막하고 어두운 새를 상상하기 시작할 것이다. 우리의 뇌는 틀린 방향으로 달리기 시작해 프로세싱 초과를 거쳐 무관한 사고로 이어진다.

문제 이해하기

스몰토크 프로그래머에게 돈을 주면서 그들이 생각할 때 조직이 필요로 하는 것을 생산하도록 요구하는 것보다 수치스러운 일은 없다. 은행가가 국제거래 자금을 대는 방식이든 유전학자가 염색체에서 유전자의 위치를 추론하는 방식이든 그들이 요청받은 문제를 이해하지 못한다면 프로젝트의 미래는 암울하다. 해결책을 요구조건 수집이라고 부르든 객체 지향 분석이라 부르든 상관없지만 이 해결책은 문제를 이해하는 사람과의 엄청난 작업 및 시간 투자를 필요로 한다. 개발자와 사용자의 경계를 넘어야 한다.

객체 지향성 이해하기

이것은 분명한 요인이다. 컨테이너, 추상 클래스, 다형성, 그리고 나머지 개념에 익숙해질 때까지 당신의 디자인은 대충 만든 것일 수밖에 없다. 그리고 상당히 큰 스몰토크 코드를 작성하기까지는 당신의 작업을 검토하고 정리할 방법을 제시하는 숙련된 스몰토크 프로그래머에게서 이익을 얻을 수 있겠다.

리더십

리더라 함은 관리자, 또는 팀 리더, 또는 프로그래머가 될 수 있다. 지위보다는 자질이 더 중요하다. 효과적인 리더들은 문제를 이해하고, 그들의 객체 지향 도구의 장점과 한계에 대한 직접적인 경험을 갖고 있다. 또한 정치적 상식도 있다: 프로젝트가 필요로 하는 지원과 자원을 확보하기 위해서 주위 조직에 충분히 익숙하다. 이러한 요소 중 하나라도 빠지게 되면 프로젝트는 실패한다. 올바르지 않은 시기에 올바르지 않은 툴이나 프레임워크를 습득하고, 그것이 습득한 것이 무엇이든 잘못 적용하게 된다. 어떤 요소가 효과가 있어서 팀이나 고객들을 기쁘게 할 수는 있지만 어떠한 문화나 규율도 강력한 제품을 지향하기 위해 노력하지는 않는다. 가장 슬픈 시나리오는, 프로그래머와 디자이너가 거대한 추상화를 형성하고 나서 일반적인 문제를 해결하고자 미친 듯이 노력하는 경우다. ("악마는 디테일에 있다,"라는 속언을 알고 있었다면 기본적이고 구체적 문제에 수많은 도전과제가 있고, 그러한 문제를 극복하기 전에는 일반 문제를 해결하려는 시도가 소용없음을 이해할 것이다.)

필자는 언젠가 소프트웨어 개발은 빅뱅(Big Bang)에서 시작된 우주와 같이 진행된다는 말을 들은 적이 있다. 핵심적인 순간에 발생하는 일이 전체적인 미래 과정의 모습을 형성할 수 있다. 특이한 개발자나 관리자를 고용, 아키텍처나 도구에 암시된 내용을 이용, 운명적으로 던진 말 -이 중 어떤 것이든 결과적으로 완전히 다른 모양과 느낌, 성능, 또는 내구성을 가진 제품으로 이끌 수 있다. 모든 결정은 다음, 그 다음, 그 다다음 결정에 영향을 미친다. 소프트웨어 개발은 날씨와 같이 혼돈의 현상이어서 한 달 전에 베이징에서 일어난 나비의 날개 짓이 현재 뉴욕의 상태를 결정짓는 것과 같다. 누구도 미래의 정확한 모습을 예측할 만큼 예지력이 있지는 않다. 다만 우리 리더의 예감이-그들의 날개 짓이-뼈아픈 실수로부터 구해주길 바랄 뿐이다.

유망한 사용자를 계속 관여시키기

비유: 1980년대 후반에 14마일 도로를 건축하기 위해 파트너십이 구성되었다. 파트너들은 승용차 운전자들에게 도로를 이용하는 비용으로 $1.75를 부과하여 이익을 거두기로 결정했다. 도로는 빠르게 증가하는 인구로 인해 고소득 구역이 될 예정이었다. 1995년, 도로가 개통되고 도로 요금소도 열렸다. 하지만 도로를 이용하는 특권에 $1.75를 지불하겠다는 운전자가 거의 없는 바람에 파트너들은 즉시 재정적 문제에 처하게 되었다. 문제는 그들 중 누구도 운전자들에게 도로가 그들에게 얼마의 가치가 있는지를 질문하지 않았던 것이다.

이것이 만일 소프트웨어 프로젝트였다면 개발자들은 유망한 사용자들을 상대로 프로젝트가 시작되기 전에, 그리고 건설이 진행되는 동안에도 여러 번 설문조사를 진행했을 것이다. 실용적인 만큼이나 개발자들은 사용자에게 그들이 전달하고자 하는 내용을 보여줄 것이다. 그것이 프로젝트를 끝마칠 때 달갑지 않은 서프라이즈를 막는 최선의 방법이다. 개발자들은 심지어 프로젝트를 만들 가치가 없다고 결정할지도 모른다.

겸손

강력한 소프트웨어를 전달하든 마라톤을 뛰든, 이전에 경험이 없는 경우 생각한 것보다 훨씬 더 많이 아플 것이다. 첫 번째 이정표(milestone)은 보통으로 만들어라. 객체 지향 디자인과 프로그래밍을 비롯해 네트워크상에 있는 데이터베이스에서 객체들을 어떻게 지속되게 만드는지, 어떻게 애플리케이션이 바람직하게 실행되도록 조정하는지를 학습할 것이다.

긍정적 결론

지금쯤이면 소프트웨어 개발의 전체적인 어려움은 객체가 발생하기 이전의 시절에 비해 별로 달라진 바가 없음을 깨달았을 것이다. 디자인, 리더십, 기술 등은 그 때도 중요했다. 양질의 소프트웨어를 생산하기란 항상 힘들었으며, 앞으로도 항상 힘들 것이다. 더 나은 툴과 기술이 도움이 되긴 하나 대부분은 툴을 빌드한 목적이 되는 작업을 충분히 이해하게 되었으니 작업을 간소화하는 데에 도움이 된다. 힘든 일은 새로운 뮨제의 유형을 이해하고 그에 대한 해결책을 설계하는 데에 있다. 우리의 툴이 얼마나 개선되든 다음 세대의 문제를 해결하기 위해서는 머리를 짜내야 할 것이다.

객체는 다형성과 패턴과 프레임워크와 같은 것을 적용함으로써 우아한 소프트웨어 해결책을 생성할 기회를 제시한다. 하지만 이러한 유행어의 소란 가운데서 우리는 객체의 기본적인 혜택을 간과해서는 안 된다. 이는 우리가 젤 먼저 살펴본 내용이다 (7 페이지): 객체는 프로그래머에게 나머지 사람들이 가진 것과 동일한 인지적 도구, 동일한 정신 과정과 은유를 제공한다. 따라서 객체는 한 사람의 마음에 있는 생각을 다른 사람의 마음으로 해석하는 비용을 줄여준다. 객체는 요구사항 분석부터 최종 검사까지 소프트웨어 사업에 걸쳐 발생하는 오해를 감소시킨다.

우리는 이러한 오해의 비용을 수량화하는 방법이나 그로부터 예방하는 방법을 알지 못한다. 오해는 방법론, 툴, 스케줄, 또는 메서드 크기, 추상 클래스의 수, 상속 계층구조의 깊이, 또는 패턴의 개수만큼 측정 가능하지 않다. 따라서 객체의 본질적인 경제적 가치를 거의 평가하지 못한다: 그들은 오해를 감소시키므로 우리는 더 나은 소프트웨어를 전달할 수 있다.