어둠 속에서 빛을 내는 코드

예광탄은 지금 맞추고 있는 것이 무엇인지를 보여주는 개념이다

• 사용자들은 뭔가 작동되는 것을 일찍부터 보게 된다
• 개발자들은 들어가서 일할 수 있는 구조를 얻는다
• 통합 작업을 수행할 기반이 생간다
• 보여줄 것이 생긴다
• 진전 상황에 대해 더 정확하게 감을 잡을 수 있다

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

프로토타입은 최종 시스템의 어떤 특정한 측면을 탐사해 보는 것이 목표다

예광탄 코드 접근 방법은 다른 종류의 문제에 대한 대응 방법이다

소프트웨어 프로토타입도 같은 이유에서 같은 방식으로 만든다

즉, 위험요소를 분석하고 노출 시키며 이를 매우 저렴한 비용으로 바로잡을 기회를 얻는 것이다

프로토타입의 대상

• 아키텍처
• 기존 시스템에 추가할 새로운 기능
• 외부 데이터의 구조 혹은 내용
• 써드파티 도구나 컴포넌트
• 성능 문제
• 사용자 인터페이스 설계

프로토타입을 만들 때 무시해도 되는 것

• 정확성 correctness : 적절히 가짜 데이터를 사용할 수 있다
• 완전성 completeness : 제한된 기능만을 제공해도 된다
• 안정성 robustness : 특수한 순서대로 실행시키지 않을 때 망가져도 괜찮다
• 스타일 style : 프로토타입 코드는 주석이나 문서를 많이 만들지 않아도 된다

아키텍처 프로토타이핑

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

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

프로토타입을 내놓았을 때, 고객이 보완하자는 요구를 해올 가능성이 있다

프로토타입은 쓰고 버리는 말 인데, 그를 보완하자고 말하는 것이다

이럴때, 예광탄을 사용할 지 프로토타입을 사용할 지 잘 판단하라

액터의 행동들을 기준으로 플로우를 구성해나가는 것

코드를 세포(모듈) 단위로 구성하고, 이들 간의 상호작용을 제한하라

그러면 한 모듈이 변경되거나 교체된다 하더라도 다른 모듈들은 변경 없이 수행될 수 있을 것이다

결합도 줄이기

의존의 증가가 어째서 나쁜 것인가?

• 논리적으로 분리된 두 개 이상의 개념들이 서로의 코드에 영향을 줄 수 있음
• 한 클래스가 너무 많은 의존 관계를 갖게되면 의존 관계가 조합적으로 폭발(combinatorial explosion) 할 수 있다. 이러한 징후는 다양한 방식으로 나타난다

1. 단위 테스트를 링크하기 위한 명령어가 테스트 프로그램 자체보다 긴 대규모 C 혹은 C++ 프로젝트
2. 한 모듈의 '간단한' 수정이 이와 관계없는 모듈을 통해 시스템 전역게 퍼져나가는 경우
3. 개발자가 수정한 부분이 시스템에 어떤 영향을 미칠지 몰라 코드의 수정을 두려워하는 경우

우리는 의존도를 최소화 하기 위해 디미터 법칙을 사용하여 메서드, 함수를 설계한다

디미터 법칙

모듈간의 결합도를 최소화하라

한 모듈은 주변 모듈을 모를수록 좋다

좀 더 구체적으로, A 가 B를 사용하고 B 가 C 를 사용한다 하더라도 A가 C를 알아야 할 필요는 없다는 뜻이다

여러 모듈에서 a.getB().getC() 라는 형태를 사용한다면 설계와 아키텍처를 바꿔 B 와 C 사이에 Q 를 넣기가 쉽지 않다. a.getB().getC() 를 모두 찾아 a.getB().getQ().getC() 로 바꿔야 하니까

너무 많은 모듈이 아키텍처를 너무 많이 안다. 그래서 아키텍처가 굳어진다

내가 사용하는 모듈이 내게 필요한 서비스를 모두 제공해야 한다. 원하는 메서드를 찾느라 객체 그래프를 따라 시스템을 탐색할 필요가 없어야 한다

모듈간의 결합도는 일정하게 유지할 수 있을지 몰라도 성능 문제가 있을 수 있다.

(이미 정의되어 있는 메소드를 다른 곳에서 연결하는 작업은 JVM 메소드 스택을 잡아먹고, 이러한 관계가 많아진다면 성능이 박살날 수 있음)

여느 기술과 마찬가지로 장점과 단점을 잘 고려하여 적용시켜야 한다