Topic 13 프로토타입과 포스트잇
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
프로토타입을 반드시 코드로 작성해야 한다고 생각하기 쉬운데 꼭 그럴 필요는 없다. 자동차 회사와 마찬가지로 다른 재료를 이용해 프로토타입을 만들 수도 있다. 포스트잇은 작업 흐름이나 애플리케이션 로직과 같이 동적인 것을 프로토타이핑할 수 있는 훌륭한 도구다.
p.80
저자는 프로토타입을 코드로 국한하지 말라고 말하고있다. 생각해보면 코드로써 항상 설명하려고 했던 것 같은데 꽤 충격적인 발상이였다. 그렇지만 다시금 생각해보면 포스트잇과 화이트보드로써 프로토타입의 역할을 충분히 할 수 있겠다는 생각이 든다. 프로토타입의 목적은 예기되는 어려움을 미리 경험해보려는 것이기 때문이다. 그러기에 도메인 지식이나 데이터 흐름 등 포스트잇과 화이트보드로 먼저 그려보고 피드백을 받아보면 시간 단축으로 이어져 프로토타입의 목적을 달성할 수 있을 것 같다.
하지만 세부 사항을 포기할 수 없는 환경에 처해 있다면 진짜로 프로토타입을 만들고 있는 게 맞는지 자문해 보라. 아마도 이런 경우에는 예광탄 방식의 개발이 더 적절할 것이다.
p.80
이전 챕터에서 설명한 예광탄을 알기 전에는 프로토타입 때 만든 코드를 재사용을 염두해서 작성해야한다고 생각했다. 하지만 저자는 프로토타입의 경우 나중에 재사용을 염두하고 작성해서는 안된다고 말한다. 필자의 경우 사내에서 앱 개발 프로젝트가 주어졌는데 이 때 프로토타입을 만들어서 사업성 여부를 먼저 보기를 원헀다. 프로토타입을 만들려고 하는데 하다보니 이것저것 완벽한 기능을 목표로 만들고 있었다. 프로토타입이든 예광탄이든 목표에 맞게 방법론을 잡고 개발하는 것이 중요하다. 결국 뭘 해야하는지 정확히 알지 못할 때 효율이 낭비되기 때문이다.
프로토타이핑은 학습 경험이다. 프로토타이핑의 가치는 생산한 코드에 있는 것이 아니라 이를 통해 배우는 교훈에 있다.
p.81
이제는 위 인용구의 의미를 약간 알 것 같다. 프로토타이핑의 목적은 딱 학습 경험이다. 재사용성, 확장성, 운영 환경 등 고려하게 되는 순간 산으로 갈 가능성이 크다.
다음은 아키텍처 프로토타이핑에서 규명할 만한 사항이다.
- 주요 영역의 책임이 잘 정의되었고 적절한가?
- 주요 컴포넌트 간의 협력 관계가 잘 정의되었는가?
- 결합도는 최소화했는가?
- 중복이 발생한 만한 곳이 있는가?
- 정의된 인터페이스와 제약 사항은 수용할 만한가?
- 각 모듈이 실행 중에 필요한 데이터에 접근할 수 있는 경로를 갖고 있는가? 모듈에 데이터가 필요한 시점에 데이터 접근이 가능한가?
이 중 마지막 항목이 가장 놀랍고도 값진 결과를 내놓기 쉽다.
p.83
가끔 클래스 구성도를 그려볼 때가 있는데 이 때 위 사항을 중점으로 생각해서 작성해도 좋을 것 같다. 언제나 설계는 틀어지지만 설계가 잘 되어있는 코드는 움직일 수 있는 건물과 같다.
Topic 13 느낌
Topic 13 에서는 프로토타입이라는 개념을 필요하고 가벼운 것으로 소개하고있다.