최적화는-신중히-하라

최적화의 맹점과 고려할 점

최적화는 좋은 결과보다 해로운 결과로 이어지기 쉬우며, 섣불리 진행한다면 더욱 그렇다.

좋은 프로그램이지만 원하는 성능이 나오지 않는다면, 아키텍처 자체가 최적화할 수 있는 길을 안내할 것이다. 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의 내부를 독립적으로 설계할 수 있어 시스템의 나머지에 영향을 주지 않고 설계할 수 있다.

이는 프로그램 완성때 까지 성능 문제를 무시하는 것이 아니라 완성된 설계의 틀을 변경하려다 보면 개선하기 어려운 구조의 시스템이 만들어지기 쉽다는 것이다.

완성 후에 변경하기 어려운 설계 요소는 API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등 컴포넌트 간 혹은 외부 시스템과의 소통 방식이다.

public 타입을 가변으로 만들면 내부 데이터를 변경할 수 있어 불필요한 방어적 복사를 유발할 수 있다. item50

컴포지션으로 해결할 수 있음에도 상속으로 설계한 public 클래스는 상위 클래스에 영원히 종속되며 성능 제약도 물려받게 된다. item18

인터페이스 마찬가지로 구현 타입을 사용하는 것이 좋지 않다. item64

성능을 위해 API를 왜곡하는 건 좋지 않은 생각! 최적화 시도 전후로 성능을 측정 -> 프로파일링 도구를 사용(Jprofiler, Yourkit…)