2004/05/02 22:06 |
기존의 만들어진 게임들의 소스를 분석하고 이것을 다시 재 사용 하는 것에 대해 이야기
할려고 합니다.
프로그래머 신입이나 경력 프로그래머들이 게임 개발의 경험을 가지고 있는 회사에
입사하면 거의가 새롭게 만드는 것보다는 기존의 소스를 분석하고 그 소스를 기반
하여 새로운 것을 만들겁니다.
신생회사에 들어가서 처음 부터 시작하는 것도 쉽지 않지만 기존의 소스를 분석해서
사용하는 것도 결코 쉬운 일이 아닙니다. 비 프로그래머인 사람들은 기존의 것을 사용
해서 만드는 거라고 쉽게 생각하는데 이런 부분을 이해 받지 못하면 프로그래머는
고생에 시달립니다..-_-;;
소스 분석시의 문제점
1. 소스를 분석한 경험이 별로 없다.
왠만한 경력자가 아니면 여러 게임을 만들어 보고 다른 사람의 소스르 본 경험이
거의 없을겁니다. 특히 신입인 경우는 더욱 그런데 온라인 보드 게임이라도
그 양이 결코 적지 않습니다. 파일 수도 많고 한 파일 당 라인도 큰 것들은 3천라인은
장난이죠..이러니 이걸 어느 부분에서 어떻게 봐야 될지 난감해 집니다.
인터넷등에서 공개된 일반적인 소스들과 그 양이 다르니 공개된 소스를 통해 분석한
경험은 크게 도움이 되지 않을 수도 있습니다.
2. 주석이 거의 없다.
사실 소스에 주석을 달으라는 이야기는 어제 오늘 이야기도 아니고 예전이나 지금이나
책이나 말을 통해 그렇게 많이 이야기 하지만 아직도 제대로 지켜지지 않습니다.
처음에는 자꾸 소스가 수정되니까 좀 만든 주석을 달자는 안이한 생각을 하다가 반 이상
만들어지면 주석을 달 곳이 너무 많아져서 주석을 달 엄두를 내지 못해서 못다는데
이런게 그대로 반영되어 코드에 주석도 없고 관련 문서로 없으니 참 난감해집니다.
3. 코드가 지저분 하다.
이건 위에 것과 관련되는데 우리나라가 미국이나 일본처럼 게임 개발에 대한 기간이
많지 않고 사실 스트크래프트가 뜨면서 인터넷을 통한 온라인 게임이 인기를 끌면서
많은 게임을 만들어졌고 그러다 보니 회사들이 초기에 질 보다는 사실 양에 의한
경쟁을 하다보니 서로 많은 게임을 만들기 위해 하나의 게임을 설계부터 잘 만든게
아니고 하나 만든 후 이 소스로 다음 게임을 만들다 보니 하나의 게임에 다른 게임의
소스가 그 대로 남아 있어 엉망 진창이 됩니다. 그리고 좀 업데이트를 많이 한 게임은
그나마 업데이트를 하면서 코드를 정리하지만 그렇지도 않은 게임들은 코드를 보면
말이 안나올 정도로 엉망입니다.
4. 물어볼 사람이 없다.
기존의 만든 사람이 이미 없는 경우에는 정말 어찌 할 도리가 없고 만든 사람이
있다고 해도 물어보기가 쉽지 않습니다.
회사가 좀 큰 경우 기존의 게임을 만든 사람은 회사의 성장과 함께 지금쯤 높은
직책에 있을 확률이 높은데 이제 막 입사한 사람이 간 크게 상급자에게 시시콜콜
물어볼 용기가 없을겁니다. 또 가까운 위치(물리적이나 직급)에 있다고 해도
그 사람도 열심히 일하고 있는데 잘 알지도 못하는데 물어보기 껄끄럽고
또 물어봐도 만든 사람이라도 그 코드를 관리 안한지 꽤 되면 좋은 대답을 받기 힘들죠.
어딜가나 모르는것 있으면 물어보라고 하지만 이것만큼 제대로 하기 힘든것도 없습니다.
위와 같은 문제들이 있으면 시간은 흘러가고 코드를 보면 부분적으로는 이해는 가는데
전체적으로는 이해가 안가고 코드를 보고 있으면 잠만 오고(-_-;;), 주위에 압박에
마음이 편치 않을겁니다.
저의 경우는 다음과 같은 방법으로 해결했습니다.
1. 막 물어봐라..
본인이 편해 질려면 묻는 수 밖에 없습니다. 소스를 코딩한 당사자가 없다면 이 코드를
사용 하는 사람에게 라도 물어봐야됩니다. 회사 입사한지 얼마 안되고 사람들이
친절하게 대해주지 못하니 질문을 하지 못해 혼자서 해결할려고 한다면 초 삽질을
해야될겁니다. 물어봐서 2-3분에 끝날것 혼자 삽질하다 하루 다 보냅니다.
저의 경우는 초반에 이사님께서(제가 맡은 게임을 만든 분이 이사님이죠) 사수를 선택해
주셔서 초반부터 부담 없이 막 물어보았습니다. 그 덕분에 회사 입사후 1주일간 회사
분위기 파악 후 소스 받은 후 1주일만에 바로 작업을 들어갈 수 있었습니다.
2.소스를 그냥 보지 마라.
일반적으로 소스를 분석하며 VC 켜 놓고 불러와서 처음부터 관련된 파일을 열어 소스를
흐름 순서로 봅니다. 이렇게 하면 부분적으로(소스를 보는 부분)는 이해가 가지만
보고 나면 뭘 봤는지 이해가 안 갈겁니다.
최선의 방법은 그대로 따라서 코딩하는 거고 그게 안되면 흐름도라도 문서를 만들어
가면서 분석하는게 좋습니다. 저는 작년에 있던 회사에서 처음 게임 서버를 만들 때는
책에 있는 전체 소스를 치면서 이해서 했고 이번 회사에서는 제 나름대로 흐름도
(딴게 아니고 소스의 흐름을 일단 큰 부분 및 기능별로 나누고 함수들을 기준으로
호출하는 함수를 화살표를 지정하면 만들었습니다.)를 만들어서 전체를 이해 했습니다.
특히 소스를 눈으로 보면 오후되면 절저로 잠이 오지만 코딩이나 흐름도를 만들면
뭔가를 하니까 잠도 안오고 목적의식도 생기고 또 다른 사람들에게 일하는 것같이
보여 좋습니다.^^
3. 분석할 것과 지금 분석 안해도 되는 부분을 분류해라.
보통 소스를 받으면 특별한 경우가 아니면 굿이 소스 모두를 분석 안해도 될겁니다.
당장은 분석할 필요 없던가 라이브러리 부분은 그냥 사용 방법만 알면 됩니다.
소스의 양이 작지 않고, 소스 분석의 시간은 회사에서 많이 주지 않으니 그걸 처음
부터 끝가지 분석할려면 시간도 많이들고 분석하다가 지쳐버릴겁니다.
그러니 일단 중요부분과 사용할 부분만 분석하고 나머지는 다음에 천천히 해도
충분합니다.
일반적으로 신입인 경우 어떻게 하던 100% 분석할려는 경향을 보이는데 그건 위험천만
합니다. 일단 객관저긍로 신입의 경우 실력 및 경험 부족으로 100% 분석이 힘든데
그걸 할려고 혼자 낑낑 걸리면 자신의 아직도 소스를 분석하고 있는데 위에서는
일 다했냐고 물어보는 사태가 벌어지고, 그러면 신입은 그 압박에 회사를 퇴사
하게 될겁니다.
4. 소스를 내가 사용 할 때 수정해라.
소스가 일단 지저분하고 주석도 없다면 그걸 보기 좋게 리팩토링 하는게 좋지만
회사에서 그런 시간은 거의 주지 않을겁니다, 그렇다고 기존걸 그대로 사용하면
두고두고 고생할겁니다.
그러니 소스 분석이 끝난 후 기능 추가등으로 소스에 수정을 할 때 관련된 부분
부터 소스를 정리하고 주석을 붙여나가도 좋을겁니다.
그러다 보면 소스의 이해는 더욱더 높아질 거고 소스도 깨끗해져서 다음에 게임을
만들 때는 이렇게 정리된 소스를 사용하니 더 좋아질겁니다.
5. 툴을 사용해라..
저도 이제 막 사용해봤는데 Source Insight 라는 툴이 소스 분석에 도움이 될것
같더군요. 소스의 변수를 클릭하면 그 변수의 정의를 보여주고 그 변수가 사용된
파일과 라인을 보여주었어 이게 어떤거고 어떻게 사용되었는지 알기 쉽습니다.
특히 C++ 같이 클래스로 이리저리 만들어진 경우에 유용합니다.
DoxyGen 사용도 추천합니다. 위에서 주석을 달때 Doxygen 방식을 주석을
단후 이 툴을 사용하여 만들어진 문서를 보면 소스가 할결 정리된 모습으로 볼수
있을겁니다.
저의 경우 위의 방법으로 했고 지금도 그렇게 하고 있습니다. 제가 맡은 게임의
기능 수정을 하면서 서서히 예전 코드를 깔끔하게 정리를 하고 아직 완벽하게
이해하지 못한부분은 수정 작업을 하다보니(전체가 아닌 부분을 보면 되죠)
이해를 하고 있습니다. 원래의 코드는 거의 없는 주석과 하나의 함수의 크기가
너무 크고 소스의 라인들이 너무 따닥 붙어 있는걸 보기 좋게 칸을 나누고
함수를 쪼개고 있으면 STL등을 사용하여 가독성을 높이고 있습니다.
기존의 소스를 분석하는건 결코 쉬운게 아니니 이런 작업을 한다면 본인이나
회사 관계자들을 잘 이해 시켜서 너무 빡빡한 일정을 잡지 말고, 소스 분석이
제대로 안된다고 의기소침해 지지 않기를 바랍니다.
PostScript by Bruceahn : BGDA에서 발췌한 내용입니다
