시작하기에 앞서

학생시절 Effective STL 에서, "알고리즘이 더 좋다" 라는 내용을 보고, 그대로 받아 들여서, 사용하다가, 동기 중 한명이 "모하러 알고리즘을 써 어차피 똑같은거 아니야?" 라고 물었을 때, "보다 더 직관적이잖아." 라고 대답을 했던것으로 기억을 한다.

하지만 제시된 예라든지, 논리적으로 설명을 하지 못해서일까, 팀프로젝트를 진행 할 때, 알고리즘을 사용 하는게 힘들게 되었다.

8개월 정도가 지나고 나서, 그 동안 다른 사람들이 짠 코드 리뷰를 하는 순간 내 직관력은 "확실이 더 좋다." 라고 결론을 냈다.

이번 포스팅은 왜 더 좋은지에 대한 증명이다.

나와있는 예는 "한 타입의 객체를 100개 담은 vector에서 특정 값을 찾고, 어떤 일을 수행하고, 지우는 작업"이다.

일반 for을 사용 했을 때 분석

Line 28 : 코드 분석가는 우선 전체를 훏는다고 생각한다.
Line 31 : 객체의 아이디가 40인 녀석을 찾는다.
Line 37 : for문 중간에 벡터를 지워버리는 현상을 발견하고, 불안감에 떤다.
Line 38 : 도중에 break 되는 것을 보고 안심한다.


알고리즘을 사용 했을 때 분석

Line 45 : 40 으로 한개의 객체를 찾는다.
Line 54 : 객체를 지운다.


증명

둘 다 똑같은 것을 수행한다. 코드의 량은 알고리즘이 많으면 많았지 더 적지는 않다. 그래도 알고리즘이 좋은 이유는 다음과 같다.

첫째, 코드 가독성이 더 좋아진다.

일반 for 문을 사용할 경우, 우선 "무슨것을 하는 for문이지?" 먼저 생각해야 한다. 이는 for 본체를 전부 다 보기 전까지는 알 길이 없다. 그러므로 리뷰어는 "모든 객체를 돌아서, 특정 아이디를 찾는다." 의 결론에 도달할 때까지 for문 전체를 다 보아야만 한다.

하지만 알고리즘의 경우, "특정 객체를 찾는다."를 코드 자체 find_if 로 직관적으로 이를 알리고 있다. 리뷰어는 이 코드를 보고, 바로 알수 있다. 어떻게 찾는지, 그건 중요하지 않다. 이런건 나중에 중요하게 될 때 보면 되기 때문이다.

그러므로 코드 가독성이 더 좋다는 뜻이다.


둘째, 코드가 좀 더 독립적으로 구성 된다.

이 이야기를 하기 전에 우선 "더 독립적인 코드일 수록 더 좋다" 를 알아야 한다. 규모가 작은 코드일 수록, 어떻게 작성을 하던, 이해하는 비용은 적게 들어 간다. 하지만 규모가 커지면 커질 수록 서로 연관된게 더욱 많아 지게 되는데, 이는 수정을 더 복잡하게 만드는 원흉이 된다.

위의 경우를 예를 들자면, 찾는 방법이 변하게 된다면, 다시 for문을 해석하고, 찾는 부분을 조사하여, 코드 수정을 해야만 한다. 하지만 "찾는 부분"이 독립적으로 있게 되면, 나는 즉시 찾는 부분만 수정을 하면 된다.

또한 "일하는 부분"이 변경하게 되면, 찾는 부분을 다시 분석할 필요 없이, 독립되어 있는 "일하는 부분"만 쉽게 찾고, 수정 할 수 있게 된다.

다시 한번 말하지만, 코드 량이 작으면 어떻게 짜든 상관 없겠지만, 몇 천 라인의 코드를 하루 종일 보게 되면, 이 코드가 무슨 코드인지 다시 분석하는 경우가 생긴다.(물론 내가 멍청해서 그런것일 수도 있다.)

Effective STL 43 항목에 이 부분이 좀 부정적 의미로 설명되는데, 나는 오히려 이런 이유 때문에 더 좋다고 생각한다.

이 외에도 알고리즘이 더 좋은 이유가 있지만, 이는 상황(최적화, 코드량, 더 복잡해질 수 있는 이유 등)에 따라 변화 되므로 여기서는 언급하지 않겠다.


참고 문헌
Scott Meyers, Effective STL(Addison Wesley : 인포북, 2002) 43항목

posted by 농사를 짓는 게임 프로그래머 최익필

댓글을 달아 주세요

  1. minary 2013.06.10 18:01  Addr  Edit/Del  Reply

    ......
    그건 주석달면 끝나잖아요?