항목 8 : 이른 최적화를 피하라. ( Don’t optimize prematurely. )

라틴 속담
채찍을 때린다고 말이 달리고 싶어지는 것은 아니다.

시작을 "라틴 속담"으로 했는데, 그 이유는, 최적화를 한다고 해서, 그게 최적화가 꼭 되는게 아니라는 말을 하고자 함에 있다. 이번 항목은, 이른 최적화가 왜 좋지 않은지, 무엇이 더 좋은 최적화 인지를 논하는 항목이다.

이른 최적화는 디자인과 코드를 보다 복잡하게 만들고 읽기 힘들게 하며, 비록 성능상에 이점이 있다 해도, 최종 목적이 되는 결과물과 비교해서 더 좋은 성능을 발휘하는 경우는 극히 드믈다.

만약, 코드를 변경하게 될 일이 생기게 될 경우, 더 변경이 까다롭게 된다. 이는 다음의 말을 생각나게 한다.

"빠른 프로그램을 정확한 프로그램으로 바꾸는 것보다, 정확한 프로그램을 빠른 프로그램으로 바꾸는게 훨씬 쉽다"

그리고, 최적화를 한다 해서 그 코드가 꼭 최적화 되는게 아닌데, 그 이유는

첫째, 프로그래머가 코드의 속도와 크기를 따지고, 병목 현상을 찾는다는 것은 매우 힘들다. 그러므로 이렇게 찾는 과정에 들어가는 시간과 그 정확성은 기대해볼만하지 못하다는 것

둘째, 프로그램은 CPU에만 영향 받지는 않는다. 네트워크, 디스크 입출력, 램 입출력, 웹 서버 대기시간, 데이터 베이스 대기 시간 등, 아무리 최적화를 한다해도, 안된는 것은 안된다는 것

총평

.. 항목 7에서 이어온 것이라 할 수 있겠다.