[일반적인 프로그래밍 원칙들]규칙55. 신중하게 최적화하라

최적화는 좋을 때보다 나쁠 때가 더 많으며, 섣불리 시도하면 더더욱 나쁘다는 것이다. 잘못된 최적화는 빠르지도 않고 정확하지도 않으며 쉽게 고칠 수 없는 시스템으로 이어진다.

 성능 때문에 구조적인 원칙을 희생하지 마라. 빠른 프로그램이 아닌, 좋은 프로그램을 만들려고 노력하라.  좋은 프로그램은 정보 은닉 원칙을 지킨다. 설계에 관한 결정은 각 모듈 내부적으로 내려진다. 따라서 그 설게는 시스템의 다른 부분에는 영향을 주지 않으면서 독립적으로 변경될 수 있다.

 설계를 할 떄는 성능을 제약할 가능성이 있는 결정들은 피하라. 설계 가운데 성능에 문제가 있다는 사실이 발견된 후에 고치기가 가장 까다로운 부분은, 모듈간 상호 작용이나 외부와의 상호작용을 명시하는 부분이다. 그 중 API, 통신 프로토콜, 지속성 데이터 형식 등이 있다. 또한 API를 설계할 때 내리는 결정들이 성능에 어떤 영향을 끼칠지를 생각해 봐야 한다. public을 사용하면 방어적 복사를 너무 많이하게 되며, 인터페이스가 아닌 구현 클래스를 사용해 버리면 api가 특정 구현에 종속되므로 개선할 수 가 없게 된다.

 최적화를 시도할 때마다, 전후 성능을 측정하고 비교해봐야 한다. 이러한 성능 비교는 프로파일링 도구를 활용하면 어디를 최적화할지 좀 더 쉽게 결정할 수 있다.

요약

빠른 프로그램을 만드려고 애쓰지 말라는 것이다. 대신 좋은 프로그램을 짜기 위해 애써야 한다. 그렇다면 성능은 뒤따라 올 것이다. 하지만 시스템을 설계 할 때, 특히 API나 통신 프로토콜, 또는 지속성 데이터 형식을 설계할 때는 성능 문제를 따져봐야 한다.