항목 7 : 적절한 규모 유지를 위해서는 '언제, 어떻게'를 아는 것이 중요하다. ( Know when and how to code for scalability. )

여기서 말하는 "적절한 규모" 는 데이터의 처리 속도의 규모 이다. 즉 성능인데, 이 성능은 빠를 수록 좋다. 책에선 '언제, 어떻게'를 아는게 중요하다.란 이야기를 하는 것이다.

그렇다면 여기서 말하는 성능 최적화의 '언제'는 언제인가?

'언제'를 알 기란 매우 어려운데, 수 많은 책에서는 '언제'에는 절대 속하지 않을 때가 있다고 한다. 바로 '초기' 이다. 프로그램 코딩의 초기에는 데이터 처리 성능엔 신경을 쓰지 말라고 한다. 왜냐하면, '이른 최적화는 항상, 프로그램이 복잡해 지기 때문' 이라 한다.

그러면 초기에 무엇을 염두해야 하는가?

바로 '얼마나 더 간결하고, 얼마나 더 정확한지' 이다. 그러면 '일반적인 답'이 나왔다. 바로, '프로그램 초기에는 최적화를 하지 않는다' 이다.  : )

그러다면, '어떻게"는 어떻게 하는가?

가장 우선 적인 것은, '세세한 부분'은 신경 쓰지 않고, '전체적인 부분'에 초점을 두고, 더 개선시킬 것을 찾아야 한다. 비유하자면, 나무를 보지 말고, 숲을 우선 본 뒤에, "어떻게 하면 숲을 더 좋게 가꿀 수 있을까?" 를 생각한 뒤에, "각 나무들을 손봐야 한다"고 책에 나온다. 프로그램 적으로 숲에 해당 되는 것이, "흐름" 이고, 나무에 속하는 것은 "함수" 일 것이다. : )

책에서의 일반적인 최적화 방법으로는 고정된 크기의 배열보다는 유연하고 동적인 데이터 할당을 사용하고, 알고리즘의 실제 복잡성을 알고 있어야 하며, 선형 알고리즘이나 가장 빠른 알고리즘을 사용하고, 선형 알고리즘보다 나쁜 알고리즘만은 피해라. 정말 벼랑 끝에 몰려서 다른 방법이 없을 때가 아니면 지수 알고리즘은 피하라. 라고 나온다. : )

총평

경험으로 보자면, '100% 공감한다" 서버를 만들 때, 초기에 여러가지 고려하면서 코딩을 시작하니, 내가 짠 코드를 일주일 뒤에 보게 되었을 때, 무엇이 무엇인지 모를 때가 간혹 있게 되는 웃긴 경우를 겪게 되었다.( 불법적인 접근, 데이터의 암호화, 동시접속, 같은 아이피일 경우 대처, 무제한 Accept .. 등등 )

그래서 모든 경우를 다 빼버리고, "접속, 데이터 처리" 만 신경쓰고 코딩을 하니, 손 쉽게 끝이 났고, 나중에서야 느긋하게 최적화에 대해서 생각하게 되는 이점을 보게 되었다.