[The Pragmatic Programmer] 실용주의 프로그래머 - 2장. 실용주의 접근법

실용주의 프로그래머 개발도서 관련 : 2장 정리

0. 개요

이 장에서는 소프트웨어 개발의 모든 차원에 적용 가능한 팁과 요령, 보편화된 프로세스들에 대해 정리하였다.

1. 중복의 해악 : 시스템을 통틀어 어떤 지식을 중복하지 말것
2. 직교성 : 하나의 지식을 여러 개의 시스템 컴포넌트에 걸쳐 쪼개 놓지 말것
3. 가역성 : 변화하는 환경에서 프로젝트를 분리하는 몇 가지 기법
4. 예광탄 : 요구사항을 모으고, 설계를 테스트하고, 코드를 구현하는 것을 동시에 가능케 하는 개발 스타일
5. 프로토타입과 포스트잇 : 아키텍쳐, 알고리즘, 인터페이스, 아이디어 등을 테스트하기 위해 프로토타입을 어떻게 사용하는가(예광탄 개발 적용이 불가능한 경우 사용)
6. 추정 : 어떤 일들이 얼마나 걸리는지 알기

1. 중복의 해악

지식 중복으로 인한 유지보수

프로그래머로서 우리는 지식을 수집하고, 조직하고, 유지하며, 통제한다.

우리는 문서화를 통해 지식을 관리하고 코드를 통해 지식에 생명을 불어넣는다. 그리고 테스트를 통해 이를 재점검한다.

하지만 불행히도 지식은 고정적이지 않다. 계속해서 변경되는 요구사항과 환경 속에서 이를 관리하기 위해 대부분의 시간을 보낼 때도 있다.

유지보수는 버그를 고치고 기능을 개선하는 것이기 때문에 출시 이후 비로소 유지보수가 시작된다고 믿는다. 그러나 이는 틀렸다. 우리는 항상 유지보수 모드에 있다.

설계나 코딩을 하던중에도 새로운 요구사항이나 환경의 변화 등의 이유로 유지보수는 일상적인 부분으로서 시작된다.

유지보수를 하려면 지식의 캡슐들을 찾아 바꾸어야 하는데 문제는 명세와 프로세스 그리고 프로그램을 개발하는 중에 지식을 중복해 넣기 쉽다는 것이다.(이럴 경우 출시 전부터 유지보수의 악몽은 시작된다…)

DRY 원칙

소프트웨어의 신뢰성을 높이고 유지보수하기 쉽게 개발하기 위한 유일한 방법은 DRY 원칙이라고 생각한다.

DRY 원칙

Don’t Repeat Yourself

모든 지식은 시스템 내에서 단일하고, 애매하지 않고, 정말로 믿을만한 표현 양식을 가져야 한다.

이를 따르지 않으면 똑같은 지식이 두 군데 이상에 표현될 것이다.

하나를 바꾸면 나머지도 바꾸어야 하고, 안바꿀 경우 모순이 발생한다. 이는 기억하느냐 마느냐가 아닌, 언제 잊어버리는가의 문제가 된다.

저자는 DRY 원칙을 ‘실용주의 프로그래머’의 도구 상자에서 가장 중요한 도구 중 하나라고 생각한다.

중복을 다루는 전략

어떻게 중복이 발생하는가?

• 강요된 중복 : 다른 선택이 없다고 느낀 개발자들. 환경이 중복을 요구하는 것처럼 보인다.
• 부주의한 중복 : 자신들이 정보를 중복하고 있다는 것을 깨닫지 못한 개발자들
• 참을성 없는 중복 : 중복이 쉬워 보이기 때문에 개발자들이 게을러져서 발생하는 중복
• 개발자간의 중복 : 한 팀(혹은 다른 팀)에 있는 여러 사람들이 동일한 정보를 중복

어떻게 해결하는가?

강요된 중복

:다른 선택이 없다고 느낀 개발자들. 환경이 중복을 요구하는 것처럼 보인다.

• 정보의 다양한 표현 양식
  • 간단한 필터나 코드 생성기 작성을 통해 빌드 시 공동의 메타데이터 표현에서 여러 개의 언어에 걸쳐 있는 구조를 만들어 낼 수 있다.
  • 클래스 정의를 온라인 데이터베이스 스키마에서 생성 혹은 애초 스키마를 만들 때 사용되었던 메타데이터에서 생성할 수도 있다.
  • 해당 책의 발췌된 코드들은 텍스트 포맷 시 전처리기에 의해 자동으로 삽입된다.
  • 한 번 하고 마는 변환이 되면 안된다. 그렇지 않으면 다시 자료를 중복하게 된다.
• 코드내의 문서화
  • 대부분 프로그래머는 훌륭한 코드에는 주석이 많다고 배운다.
  • 하지만 나쁜 코드야말로 많은 주석을 필요로 한다.
  • DRY 원칙에 의하면 낮은 차원의 지식은 코드에 포함시키고, 주석은 다른 높은 차원의 설명을 위해 아껴두라고 한다.
  • 그러지 않을 경우 지식을 중복하게 되고, 변경할 때마다 매번 코드와 주석 모두 바꾸어야 한다.
  • 주석은 필연적으로 낡게 되어있다. 믿을 수 없는 주석은 주석이 전혀 없는 것보다 더 심각한 문제를 만든다.
• 문서화와 코드
  • 보통 문서작성 후 코드를 짠다. 변경사항이 있을 경우도 문서 수정 후 코드를 갱신한다.
  • 하지만 마감일정이 다가오면서 문서의 갱신은 뒤로 미루기 쉬워진다.
  • 한 프로젝트의 사례에서 테스트 명세가 명확한 상황에서 모든 테스트를 통과해야 하는 요구사항을 만족하기 위해, 문서 자체가 테스트를 자동 생성하도록 하였다. 이를 통해 명세가 수정되면 테스트도 자동으로 변경되었고, 클라이언트가 직접 인수 테스트를 생성할 수 있도록 하였다.

부주의한 중복

: 자신들이 정보를 중복하고 있다는 것을 깨닫지 못한 개발자들

• 설계 실수의 결과로 나타나는 중복
  • ex) 트럭(속성 : 유형, 등록번호, 운전사), 배달 경로(속성 : 경로, 트럭, 운전사)의 두 도메인이 있을 경우 트럭 운전사가 바뀌게 되면 어떻게 되겠는가?? 중복으로 인한 문제가 발생한다.
    • 내재하는 비즈니스 모델에 따라 정규화하라.
    • 비정규화된 데이터는 피하도록 하라.
  • ex) 선(Line) 클래스(속성 : 시작 점, 끝 점, 길이)가 있다. 그럴싸해 보이지만 길이는 시작과 끝 점으로 정의된다는 점에서 중복이다. 점 중 하나라도 바뀌면 길이 또한 바뀐다.
• 성능상의 이유로 DRY 원칙을 위배해야 할 때
  • 비용이 많이 드는 연산의 경우 데이터를 캐싱해야 하는 경우 종종 발생한다.
  • 여기서 요령은 영향을 국소화하는 것이다. 바깥에 DRY 원칙의 위배가 노출되지 않고, 클래스 내의 메서드들만 고생하도록 하면 된다.

참을성 없는 중복

: 중복이 쉬워 보이기 때문에 개발자들이 게을러져서 발생하는 중복

• 돌아가는 길이 지름길이다.
  • 당장의 지름길 선택시 당장 몇 초를 절약하더라도, 나중에 몇 시간을 잃게 될지 모른다.
• 참을성 없는 중복은 발견하기도 쉽고 다루기도 쉬운 형태이므로 다음을 잘 지켜야 한다.
  • 나중의 고통을 피하기 위한 훈련
  • 미연에 시간을 투자할 의지

개발자간의 중복

: 한 팀(혹은 다른 팀)에 있는 여러 사람들이 동일한 정보를 중복

• 참을성 없는 중복과 달리 발견하거나 다루기 가장 어려운 유형의 중복
  • 전체 기능 집합이 부주의하게 중복
  • 수 년 동안 발견되지 않을 수 있음
  • 유지보수 문제로 귀결 됨
• 필자가 생각하는 최선책은 개발자간에 적극적이고 빈번한 소통을 장려하는 것
  • 공통의 문제를 다루기 위한 토론장을 만들어라.
  • 한 사람의 팀원에게 프로젝트 내에서 지식 교환을 도와주는 역할을 하도록 맡겨라.
  • 소스 트리의 한 가운데에 유틸리티 루틴과 스크립트들이 저장될 수 있는 장소를 마련하라.
  • 코드 리뷰시 다른 사람의 소스코드와 문서를 읽도록 하라.
  • 다른 사람들의 것들을 기웃거리는것이 아닌 통해 배우는 것이다.

Tip12 : 재사용하기 쉽게 만들라.

우리가 조성해야 하는 환경은 뭔가를 직접 만들기보다 기존의 것을 찾고 재사용하기 쉬운 환경이다.
그게 쉽지 않다면 사람들은 재사용하지 않을 것이고. 재사용에 실패한다면 지식 중복의 위험을 각오해야 한다.

2. 직교성

직교성이란

직교성

기하학에서 빌려온 용어

그래프의 축과 같이 두 직선이 직각으로 만나는 경우를 말함

컴퓨팅에서 이 용어는 일종의 독립성이나, 결합도 줄이기를 의미한다.

하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 한다.

직교적이지 못한 시스템은 하나의 변경 사항이 다른 무언가에 파생적인 영향력을 끼치게 된다. 상호작용 하는 관계로 엮여있는 것이다.
비직교적인 시스템은 본질적으로 변화와 조정을 하기 복잡하다.

Tip13 : 관련 없는 것들 간에 서로 영향이 없도록 하라.

직교성의 장점

1. 생산성 향상

• 개발 시간과 테스트 시간 감소
  • 큰 덩어리를 만들기보다 작은 단위의 자족적인 컴포넌트를 작성하는 것이 더 쉽다.
  • 간단한 컴포넌트들은 설계, 코딩, 단위 테스트를 진행하고 잊어버릴 수 있다.
  • 새로운 코드 추가 시 기존 코드를 계속 바꿀 필요가 없다.
• 재사용 촉진
  • 컴포넌트에 명확하고 잘 정의된 책임이 할당되어 있다면, 새로운 컴포넌트에 이를 결합하여 사용할 수 있다.
  • 시스템이 느슨하게 결합되어 있을수록 재설정하고 리엔지니어링하기 쉽다.
• 미묘한 생산성의 향상
  • 컴포넌트 두 개가 각각 M, N 가지 일을 할 경우, 둘을 결합하면 M x N 가지 일을 할 수 있다.
  • 두 컴포넌트가 직교적이지 못할 경우 겹치는 부분이 있을 테고, 결과물이 할 수 있는 일은 그 이하일 것이다.
  • 단위 노력당 더 많은 기능 확보가능

2. 리스크 감소

• 감염된 코드는 격리된다.
  • 병걸린 모듈이 있을 경우에도 나머지 부분으로 증상이 전파되는 것을 막을 수 있음.(아픈 부분만 치료하면 됨)
• 잘 깨지지 않는 시스템
  • 특정 부분의 변경으로 인해 발생하는 문제점은 그 부분에만 한정 된다.
• 더 많은 테스트 가능
  • 직교적인 시스템은 테스트 및 실행하기 더욱 쉽기 때문에 더 많은 테스트를 하게 됨
• 써드파티 컴포넌트 연결 인터페이스들이 작은 부분에 한정되기 때문에 특정 벤더나 제품, 플랫폼에 덜 종속적이다.

직교성의 원칙 실무 적용

프로젝트 팀

팀 내 업무가 겹치는 영역이 많다면 구성원들은 책임 영역에 대해 혼동하게 된다.(무언가 바뀌면 전체 팀원이 모여야 함.)

책임이 잘 정의된, 중복이 최소화된 그룹으로 팀을 조직하기 위한 간단한 답은 없다.

주된 인프라 컴포넌트(DB, 미들웨어 레이어 등)마다 서브팀을 할당하고, 애플리케이션 기능도 분할한 뒤 현재의 가용 인원을 확인하고 조직을 적절하게 개편한다.

프로젝트 팀 구조의 직교성을 측정하는 방법은 요청된 개별 변화에 대한 토론 참여인원 수를 확인하는 것이다. 클수록 직교성은 낮다.

설계

시스템은 협력하는 모듈간의 집합으로 구성되어야 하고, 각 모듈은 다른 부분과 독립적인 기능을 구현해야 한다.

때로는 이런 컴포넌트들이 레이어로 조직되기도 하는데, 각 레이어는 하나의 추상화 층을 이루게 된다.

레이어

• 레이어적 접근은 직교적 시스템을 만드는 강력한 방법이다.
• 각 레이어는 밑에 있는 레이어들이 제공하는 추상화만 사용
• 그렇기 때문에 코드에 영향을 끼치지 않으면서 아래에 있는 다른 구현들을 바꾸는 높은 유연성을 제공한다.
• 레이어는 또한 모듈 간에 종속성이 빨리 늘어나는 위험을 감소시킨다.

직교적 설계 확인 방법

• 특정 기능에 대한 요구사항을 극적으로 변경할 시 몇 개의 모듈이 영향을 받는가?
  • 직교적인 시스템에서는 ‘하나’여야 한다.
• 현실 세계의 변화와 설계 사이의 결합도를 얼마나 줄였는가?
  • 자신의 힘으로 제어할 수 없는 속성에 의존하지 마라. (ex. 전화번호를 식별자로 했을 경우, 지역 번호를 재할당한다면?)

툴킷과 라이브러리

써드파티 툴킷이나 라이브러리를 도입할 때, 직교성을 보존할 수 있는지 살펴봐라.

만약 툴킷이나 다른 멤버가 작성한 라이브러리를 도입할 때에도 우리의 코드에 있어서는 안 될 변화를 강요하고 있지는 않은지 검토하라.

AOP 는 직교성을 높여주는 좋은 예시이다. 적용 전 분산되어 있는 코드를 한 곳에 모아두고, 본 로직과 독립적으로 수행되도록 하기 때문이다.

코딩

코드의 작성은 언제나 직교성을 떨어트릴 수 있는 위험성을 지니고 있다. 의도치 않게 다른 모듈에 중복 기능을 구현하거나 동일 지식을 표현할 수 있기 때문이다.

직교성 유지를 위한 코딩 기법

• 코드의 결합도를 줄여라.
  • 부끄럼타는 코드(shy code)를 작성하라.
  • 즉, 불필요한 어떤 것도 다른 모듈에 노출하지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라.
  • ‘디미터 법칙’을 따르려 노력해라.
    • 디미터 법칙 : 그리스 신화의 농업, 결혼, 사회 질서의 여신. 디미터라는 프로젝트에서 발견한 법칙. 모듈간 결합도를 낮추기 위한 법칙이다. 자세한 설명은 나중에…
  • 객체 상태를 변경할 때는, 객체 스스로가 우리를 위해 그러한 일을 수행하도록 만들어라.(다른 코드 구현으로부터 분리, 직교성 유지)
• 전역 데이터를 피하라.
  • 전역 데이터를 참조하는 순간 해당 데이터를 공유하는 모든 컴포넌트와 엮이게 된다.
  • 싱글톤 패턴을 주의하여 사용하자.
    • 전역의 개념으로 남용하지 말자.
    • 불필요한 링크를 유도한다.
• 유사한 함수를 피하라.
  • 중복 코드는 구조적 문제의 징후다.
  • ‘디자인 패턴’에서 소개하는 스트래티지 패턴을 사용하여 더 나은 구현은 없는지 고려하자.(ex. 시작과 끝이 동일하고 중간의 알고리즘이 다른 경우.)

기회가 있을 때마다 코드의 구조와 직교성을 향상시키기 노력해야 한다. 이러한 프로세스를 리팩터링이라고 한다.

테스트

시스템 컴포넌트 간의 상호작용이 형식화되고 제한된 경우 각각의 모듈 수준에서 테스트를 수행 할 수 있어 테스트하기 더욱 쉽워진다.

모듈 테스트는 통합 테스트 작성보다 훨씬 쉽다.

모든 모듈이 자신만의 단위 테스트 갖고, 테스트가 정규 빌드 과정의 일부로 수행되어야 한다.

단위 테스트를 만드는 작업만으로도 직교성을 테스트해볼 수 있다.

버그 수정은 시스템의 직교성을 총체적으로 점검할 수있는 시간이다.

문제가 발생했다면 버그 수정이 얼마나 지역화 되어있는지 평가하라. 버그 수정후 소스코드 관리 툴을 통해 버그에 대해 태그를 남겨라. 이는 버그 수정시 얼마나 많은 소스가 영향을 받았는지 확인할 수 있게 해준다.

문서화

내용과 표현이 두 축이 되어 문서에도 직교성이 적용된다.

직교적인 문서라면 내용 변화 없이 표현을 극적으로 바꿀 수 있다.

3. 가역성

당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다. - 에밀 사르티에, 종교론, 1938

가역성

이것은 이 방법으로만 해결할 수 있어와 같은 근시안적인 생각을 갖고 프로젝트에 참여한다면 아마도 예상치 못했던 경우에 의해 한숨지을 일들이 많을 것이다.

어떠한 결정을 돌에다가 새긴다고 가정하면, 발생할지도 모를 우연한 사건들에 대해 준비하지 않는 데에서 실수가 나오기 마련이다.
반대로 결정을 해변가의 모래 위에 쓰인 글씨라고 생각해보면, 언제든지 큰 파도가 글씨를 지워버릴 수 있다.

Tip14 : 최종 결정이란 없다.

유연한 아키텍처

많은 사람들이 코드를 유연하게 유지하려고 노력한다. 하지만 아키텍처, 배포, 벤더 통합 영역의 유연성에 대해서도 관심이 필요하다.

• 설정 파일 하나만 변경해도 독립형, 클라이언트-서버, n-티어 모델 중 하나를 지원할 수 있도록 하는 방안을 미리 생각해보자.
• 특정 벤더 제품에 대한 의존도 등은 잘 정의하고 추상화한 인터페이스를 통해 감출 수 있다.
• 무언가 자동으로 추가할 수 있다면, 자동으로 빼낼 수도 있다.

누구도 미래에 대해 알 수 없으며, 우리도 예외는 아니기 때문에 우리들의 코드를 고정할 수도 있고, 유연하게 만들 수도 있도록 만들자.

4. 예광탄

사람들이 힘든 계산보다 예광탄을 더 좋아한다.

왜냐하면, 즉각적인 반응과 실제 탄환과 동일한 환경 조건에서 날아가기 때문에 외부의 영향도 최소화된다.

새로운 프로젝트에서도 마찬가지로 예광탄은 필요하다.

예광탄의 효과

• 일반 탄환과 동일한 환경과 제약 조건에서 발사되고 날아간다.
• 타환이 목표물에 도달하는 시간이 짧다.
• 기관총 사수는 즉각적인 반응을 얻을 수 있다.
• 상대적으로 비용이 적게 든다.

어둠 속에서 빛을 내는 코드

코딩에서 예광탄과 동일한 효과를 얻기 위해 우리를 요구사항에서 최종 시스템의 일부 측면까지 빨리 눈에 보이게 반복적으로 도달하게 해줄 무언가를 찾아야 한다.

Tip15 : 목표물을 찾기 위해 예광탄을 써라.

예광탄 코드는 나중에 버리려고 만드는 것이 아니다. 계속 사용할 코드다.

예광탄 코드에도 상용 코드와 마찬가지로 모든 에러 검사, 구조화, 문서화, 자기 검사가 포함된다.
단지, 아직 완전한 기능이 들어있지 않을 뿐이다.

하지만 시스템을 구성하는 모든 요소들을 연결해 놓은 후기 때문에 목표물에 얼마나 가까이 다가섰는지 확인하고 조정할 수 있다. 목표물을 맞춘 뒤 기능을 추가하는 것은 쉽다.

예광탄 개발 방법은 프로젝트는 결코 끝나지 않는다는 관념과도 일맥상통한다. 변화는 언제나 계속 생기기 마련이다. 예광탄 개발 방법은 점진적인 접근 방법이다.

반대되는 전형적인 방법은 거대 공학적 접근 방식이다. 이는 모듈 단위로 분류된 코드가 모두 완성되어야 조립을 통해 전체 애플리케이션을 볼 수 있는 방식이다. 완성작을 사용자에게 보여주기까지 많은 시간이 걸린다.

예광탄 코드 접근 방법의 장점

• 사용자들에게 일찍 보여줄 수 있는 결과물
  • 기능이 없다고 실망하지 않고, 자신이 쓸 시스템의 진전을 눈으로 볼 수 있어 기뻐할 것이다.
  • 프로젝트가 진행됨에 따라 기여하기 시작할 것이며, 점점 관심도가 높아질 것이다.
  • 사용자들은 프로젝트가 얼마나 목표물에 가까이 도달했는지 알려줄 척도가 된다.
• 들어가자마자 일할 수 있는 구조
  • 이미 모든 요소간 상호작용과 코드 구체화까지 해 놓은 상태.
  • 이 덕분에 투입될 개발자들의 생산성은 좋아지고, 일관성도 촉진된다.
• 통합 작업을 수행할 기반이 생김
  • 시스템 요소들이 모두 연결된 다음에야 코드를 추가 할 수 있는 환경이 생긴다.
  • 한꺼번에 모든 것을 통합하려고 노력할 필요 없이 매일 통합할 수 있다.
  • 새로운 변화가 어떤 영향을 주는지 명확하게 파악 가능하며, 상호작용들은 더 제한적이다.
  • 디버깅과 테스팅 속도가 빨라져 더 정확해진다.
• 보여줄 것이 생김
  • 후원자 또는 고위층 인사들의 경우 데모를 보고 싶어 하는 경향이 있음
  • 예광탄 코드 방법에는 보여줄 무엇인가가 언제나 마련되어 있다.
• 진전 상황에 대한 정확한 감각
  • 예광탄 코드 개발 방법에서 개발자들은 유스 케이스를 한 번에 하나씩 다룬다.
  • 이러면 수행을 평가하기도 쉽고 사용자들에게 얼마나 진전되었는지 보여주기도 쉽다.

예광탄이 언제나 목표물을 맞추는 것은 아니다

예광탄은 맞춘 것이 무엇인지를 보여줄 뿐 그것이 꼭 목표물이라는 보장은 없다.

그럴 경우 목표물이 맞을 때까지 조준을 옮겨야 한다. 이것이 핵심이다.

처음 몇 번의 시도가 목표물에 맞지 않아도 놀랄 필요가 없다. 지금 있는 것을 목표물에 가까이 가져가려면 어떻게 바꾸어야 할지 생각해내고, 가벼운 개발 방법론을 선택했다는 것만으로도 감사해야 한다.

코드의 크기가 작으면 관성 역시 약하므로 빠르고 쉽게 바꿀 수 있다.

예광탄 코드 vs 프로토타이핑

혹자는 예광탄 코드는 프로토타이핑과 다를 바 없다고 생각할지도 모른다. 그러나 다른 점이 있다.

프로토타이핑

• 프로토타입은 최종 시스템의 어떤 특정한 측면을 탐사해 보는 것이 목표다.
• 구현을 시도할 때 대충 끼워 맞춘 것들을 모두 버린 다음 과정에서 얻은 교훈을 바탕으로 다시 코드를 만들게 된다.
• 어떤 경우든 일단 결정을 내린 후라면, 다시 처음부터 시작해서 현실 세계와 상호작용하는 최종 환경의 코드를 작성하게 된다.

예광탄 코드

예광탄 코드는 다음과 같은 목표를 가지고 있다.

• 애플리케이션이 전체적으로 어떻게 연결되는지 알리기
• 사용자들에게 실제로 애플리케이션 요소들이 어떻게 상호작용하는지 보여주기
• 개발자들에게 코드를 붙일 아키텍처적 골격을 제시하기

그렇기에 복잡한 구체적인 구현은 대강 진행하고, 단순하지만 동작은 하는 사용자 인터페이스로 구성된 예광탄을 만들어 제시하는 것이다.

이렇게 애플리케이션의 모든 요소들을 이어붙이면 사용자들과 개발자들에게 보여줄 프레임워크가 생긴다.

이 후 프레임워크는 손대지 않고 그대로 남으며, 첫 예광탄 코드가 완성되었을 때 해당 시스템이 앞으로 그 방식 그대로 동작하리라는 점을 알게 된다.

궁극적인 차이점

• 프로토타입은 나중에 버릴 수 있는 코드를 만듦.
• 예광탄 코드는 기능은 별로 없지만 관결된 코드이고, 최종 시스템의 골격을 이룸.

프로토타입은 예광탄이 발사되기 전 먼저 일어나는 정찰과 정보 수집 정도로 생각하면 되겠다.

5. 프로토타입과 포스트잇

프로토타입을 통해 위험 요소를 분석하고 노출시키며 이를 매우 저렴한 비용으로 바로잡을 수 있다.

프로토타입은 반드시 코드로 작성해야 하는 것은 아니다.

• 포스트잇 활용 - 작업 흐름 파악, 동적인 애플리케이션 로직 파악
• 화이트보드 - UI 파악
• 페인트 프로그램, 인터페이스 빌더 등 …

기능은 구현하지 않고 인터페이스만 그려보는 방법으로 프로토타입을 만들 수 있다.

프로토타입은 제한된 몇 가지 목적만 달성하기 위해 설계되기 때문에 실제 제품보다 훨씬 적은 비용으로 빠르게 개발할 수 있다.

하지만 만약 세부사항을 포기할 수 없는 상황에서는 프로토타입 보다는 예광탄 스타일이 적절할 것이다.

프로토타입 대상

위험을 수반하는 모든 것이 프로토타입의 대상이다.

• 이전에 해본 적이 없는 것
• 최종 시스템에 매우 중요한 것
• 증명되지 않은 것
• 실험적인 것
• 의심 가는 것
• 심적으로 편하지 않은 것

프로토타입은 학습 경험이며, 프로토타입의 가치는 생성된 코드에 있는 것이 아닌 이를 통해 배우게 되는 교훈에 있다.

Tip16 : 프로토타입을 통해 학습하라.

어떻게 사용할 것인가?

프로토타입에서 무시해도 좋은 항목

• 정확성 : 가짜 데이터 사용
• 완전성 : 제한된 기능만 제공
• 안정성 : 에러 인정
• 스타일 : 주석 또는 문서를 만들지 않아도 됨

아키텍처 프로토타이핑

예광탄과 달리 프로토타입 시스템의 모듈은 꼭 기능을 가져야 하는 것은 아니다.

아키텍처를 프로토타이핑할 때 코드가 아닌 화이트보드, 포스트잇, 인덱스카드 등을 사용해도 된다.

오직 전체적으로 시스템이 어떻게 동작할지에 대한 감을 잡는 것이 목적이다.

아키텍처 프로토타입에서 규명할 만한 사항

• 주요 컴포넌트의 책임이 잘 정의되었고 적절한가?
• 주요 컴포넌트 간의 협력관계가 잘 정의되었는가?
• 결합도는 최소화되었는가?
• 잠재적 중복을 찾아낼 수 있는가?
• 인터페이스 정의와 제약 사항은 수용할만한가?
• 각 모듈이 실행 중에 필요로 하는 데이터에 접근할 수 있는 경로를 갖고 있는가?
• 모듈은 데이터를 필요로 할 때 데이터에 접근할 수 있는가?

어떻게 프로토타입을 사용하지 않을 것인가?

프로토타입을 코딩할 때는 모든 사람들에게 폐기될 코드를 작성하고 있다는 것을 알려야 한다.

프로토타입은 완벽해 보여서는 안된다. 후원자 혹은 관리자가 적절히 완성된 프로토타입을 그대로 사용하거나 보완하여 배포하자고 주장할 수 있기 때문이다.

고찰

⬅️ 실용주의 프로그래머 목차보기