최적화를 할 때는 다음 두 규칙을 따르라.
첫 번째, 하지 마라.
두 번째, (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화 된 해법을 찾을 때까지는 하지 마라.
[M.A 잭슨]
빠른 프로그램보다는 좋은 프로그램을 작성하자
- 정보 은닉을 따르는 좋은 프로그램은 내부를 독립적으로 설계 가능하다(item-15)
- 최적화는 좋은 프로그램을 만든 이후에 개별적으로 진행 가능하지만 아키텍처의 결함은 시스템 전체를 다시 작성해야 한다.
성능을 제한하는 설계를 피하자
- 외부 시스템과의 소통 방식은 완성 후 변경이 어렵다. ex) API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등
- 위는 설계시 반드시 성능을 염두에 둬야 한다.
API를 설계할 때 성능에 주는 영향을 고려하자
- public 가변 타입 -> 방어적 복사를 수없이 유발(item-50)
- 컴포지션으로 해결 가능함에도 상속 방식으로 설계된 public 클래스 -> 상위 클래스에 영원히 종속됨(item-18)
- 인터페이스가 아닌 굳이 구현 타입을 사용 -> 종속됨 (item-64)
성능을 위해 API를 왜곡하지 말자
- 잘 설계된 API는 성능도 좋은게 보통임
- API를 왜곡하도록 만든 그 성능 문제는 해당 플랫폼이나 아랫단 S/W 다음 버전에 사라질 수도 있으나 이를 지원하는데 따르는 고통은 계속된다.
잭슨 어록 두가지 + 최적화 시도 전후의 성능 측정
- 시도한 최적화 기법이 결국 최적화 기법이 아닐 수가 있음
- 심지어는 더 나빠지게 할수도🥺
- 성능의 90%의 시간을 단 10%의 코드에서 사용한다는 사실을 기억하자
- 어느 지점에서 시간이 많이 소요되는지 확인하고 최적화를 수행하자(프로파일러 사용)
- 어떤 알고리즘을 사용했는지 확인하자. 저수준 최적화는 아무리 해봐야 소용X
백엔드 개발자