ProgC's life

어제 메트로 타운에 점심 먹으러 갔다가 eb에 들려서 사왔습니다. 개발자로써의 느낌은 그냥 '만들었다'정도였습니다. 요새 너무 거대 개발사들이 게임을 잘 만들어서 그런지 완성도 면에서 뭔가가 부족한 느낌이 많았습니다.

가장 크게 실망한 점은 멀티 플레이시에 대화 하는 부분이 전혀 없다는 점입니다. 그래서 그런지 게임을 하면서 적적한 느낌이 계속 들더군요. 그냥 모드만 만들었다라는 느낌이지... 그 안에 내가 유령을 친구들과 잡고 있다는 생각이 전혀 안들었습니다. 이번에 SF4의 경우에 커멘터리 시스템이 굉장히 잘 만들어져 있는데 그 정도는 구현해 주었으면 게임 하는 동안에 4명의 캐릭터가 서로 대화를 하면서 "이야호~!~~~~~"하는 느낌만 구현해 주었다면 얼마나 좋았을까 싶습니다.

둘째로 프레임 저하가 굉장히 심하더군요. 특히 낚시 하는 선장을 잡는 부분이 있는데 물을 실제 시뮬레이션으로 돌렸는지 굉장히 느리더군요. 차라리 그냥 텍스쳐로 발랐으면 하는 생각이 들었습니다.

셋째, 인디케이터가 전혀 없습니다. 길 잘 잃어 버리는 사람들에게는 아마 공포의 게임이 될 듯. 저는 순간 버그인가 했습니다. 알고보니 어두운 구석에 동료가 한명 있었는데... 보이질 않더군요...

넷째, 사운드가 안나오는 버그
음... 지금 이 버그 때문에 챕터 진행을 안하고 있습니다. 59.99달러 내고 샀는데...;
요새 제가 다른 사람이 만든 게임에서 버그를 보다 보니... 걱정되는군요... 게임 말고 버그나 잡으러 가야겠네요.

요즘에 정말 죽도록 코딩만 합니다... 이제 곧 다음 게임도 나오게 될텐데...
정말 잘하지 않으면 안되기 때문에... 미치도록 하고 있습니다...만 이거 뭐야...
끝이 없어;;;

프로그래밍을 할 때 많은 사람들은 도큐먼트화를 하지 않습니다. 왜냐하면 코드 자체로 모든것을 설명할 수 있기 때문입니다. 이것은 충분히 설득력이 있는 주장입니다만 문제는 코드만 보고 이해를 하는데 있어서 제 3자가 원저자에 상응하는 경험이 있다는 전제가 깔려 있습니다. 그렇지 않을 경우는 코드를 이해하는데 엄청나게 많은 시간이 소비됩니다.

오늘은 제가 일을 하면서 주로 적용하는 가이드 라인을 적어 보도록 하겠습니다.

1. 주석을 남용하지 않는다.
예를 들어서 Player 클래스의 GetPosition메소드에는 주석을 전혀 쓸 필요가 없습니다. 왜냐하면 클래스를 사용하는 사람은 위치가 필요할 때 저 메소드를 사용하면 됩니다. 다만 현재 위치와 미래의 위치 혹은 이전의 위치를 리턴하는 메소드가 따로 있을 경우에는 다음과 같이

GetCurPosition, GetFuturePosition와 같이 사용하면 됩니다. 만일 동일한 이름으로 사용할 경우에는 GetPosition(float futureDt = 0.0f) 같이 사용할 수 있습니다. 이렇게 되면 굳이 주석이 필요가 없습니다.

2. 소스 관리 프로그램을 사용한다.
시중에는 퍼포스를 포함한 여러 소스 관리 프로그램들이 존재합니다. 이러한 프로그램을 사용하면 코드가 언제/어떻게/누가 바꾸었는지를 다 알 수 있습니다. 그리고 아직 회사에 일하는 사람이 있다면 그 사람에게 구현 내부 사항을 바로 물어보면 되는 일입니다.

3. 도큐먼트화를 한다.
이제 가장 중요한 문서화입니다. 2번에서 설명한 바와 같이 같은 회사에 있으면 그냥 메일이나 직접 자리에 찾아가서 물어보면 되는 일입니다. 이때 문서화가 정말 중요한 역할을 하게 됩니다. 왜냐하면 같이 일하는 동료의 시간이 굉장히 비싼 사람들에게 있어서는 10분, 30분도 상당히 많은 비용과 낭비를 초래합니다. 왜냐하면 답변자가 다시 집중하는데 있어서 시간이 꽤 걸리기 때문이죠. 이때 문서가 있으면 굳이 종이에 다시 써서 설명할 필요가 없습니다. 그냥 와이트 보드나 프린터물을 보여주면서 설명해주면 곧바로 이해가 가능하기 때문입니다.

4. 설명하는데도 방법이 존재.
이제 어떻게 문서화를 하는지가 관건입니다. 문서화를 하는데 있어서 제가 정말 자주 사용하는 것은 UML입니다. UML의 클래스 다이어그램과 시퀀스 다이어 그램을 가장 많이 사용합니다. 이때 중요한 것은 개념만 설명하는 것입니다.

구현 내부 사항은 일반적으로 알 필요가 없습니다. 그리고 구현 내부 사항을 알아야 할 정도라면 코드 외에는 아무런 방법이 없습니다. (같이 책상에서 코드 하나하나 설명하는 방법도 괜찮은 방법입니다.)

구현 내부 사항을 일반적으로 자세히 알필요가 없기 때문에 문서화를 할 때 포인트는 어느 한 시스템의 부분 부분들을 개괄적으로 어떻게 돌아가는지를 설명하는 것이 문서화 하는 포인트입니다. 이렇게 되면 누군가가 새로운 시스템을 추가 하려고 한다거나 할 때 문서나 다이어그램을 보면서

"그래 여기에 우리가 만들 시스템을 넣으면 좋겠다."

라고 이야기가 진행되고 동의 혹은 다른 의견을 얻어내서 일을 진행하는 것입니다.

혹은 "내가 지금 하려고 하는건 xxxxx인데 이미 존재하는 것인가?"라는 질문에도 바로
답변이 나올 수 있습니다.

저는 문서화 혹 다이어그램을 그릴 때 항상 개괄적으로만 합니다. 하지만 중요한 부분에 있어서는 상당히 자세하게 하는데 지금까지 경험으로 볼 때 자세하게 해서 지금까지 이해한 사람이 거의 한두명 정도라는 것입니다. 너무 자세하게 적어도 결국 같이 코드 보면서 설명할 수 밖에 없다는 이야기 입니다.


하고 싶은 말은 이게 전부입니다. 아직도 너무 많은 프로그래머들이 문서화를 하지 않습니다. 코드가 전부다, 문서화 할 시간이 없다. 라는 것이 대부분의 이유인데 저는 그런 사고 방식을 가진 사람들은 대부분 일을 효과적으로 하지 못하기 때문에 그렇지 않나 라는 생각을 합니다.

코드가 전부다. 라고 하는 사람들 중에 정말 코드 머신일 정도로 일을 하는 사람들도 드물고(자신이 남의 코드 분석할 때는 또 잣대가 달라진다는것도 의심해볼 여지가 있습니다.) 시간이 없다는건 불행하게도 이후에 다가올

유지, 인수인계, 코드의 질, 시스템의 컨시스턴시 (이름이 생각 안나네요 -.-...) 등...
악의 근원입니다. 시간에 쫓겨서 코드를 작성하면 그냥... 결과가 좋은 적이 단 한번도 없었습니다. (저는 이럴 때 제 스스로에게 화가납니다. 왜냐하면 다가올 후 폭풍을 알고 있거든요;;)

좋은 코드는 구현자가 확실하게 시스템을 이해하고 (내부 사항은 아니더라도 최소한의 개괄) 현재 시스템을 깨지 않고 make sense하게 코드를 작성하는 것이 이후에 올 유지, 인수인계(자신이 이해했을 때 남한테 알려줄 수 있습니다.), 코드의 질 등등 모든 것이 좋아 집니다.

자신이 코딩을 할 때 이해가 안되거나 시스템이 오동작 할 때는 조금 뒤로 물러나서 전체를 보는것이 도움이 됩니다. 나무만 보는 것 보다는 숲을 보는 것이 큰 시스템에서 일을 할 때 많은 도움이 됩니다.


결론
1. 주석의 최소화
2. 소스관리 프로그램 이용
3. 문서화
4. 개요를 다루는 문서
5. 핑계는 더 이상 그만.

요새는 작업이 끝나고 집에와서 게임을 합니다. 어제 랭킹이 5천위 정도였는데 오늘은 더 떨어지겠네요. 현재 승률은 76%이고 류,켄,장기에프,단으로 플레이를 합니다.

역시 이번작에도 -> MK * LP+LK를 통한 잡기가 가능하며 중단차기, 내려찍기, 페이크에 이어지는 켄의 얍삽함에 제 스스로 치가 떨립니다.

이번작에는 sf3에 있던 패리가 사라졌는데 굉장히 아쉽네요. (물론 한번은 가능하긴 합니다만) 아무튼 세계랭킹 1천위까지를 목표로 달려봅니다. :^)

저는 C++을 배울 때 C++ Primer을 꼭 보라고 강력하게 추천하고 싶습니다. 흔히들 C++을 배운다고 한다면 C++ Primer Plus나 TCPL을 읽는데 이 3권을 다 읽어본 저로서는 리프만의 책이 최고라고 할 정도입니다. 한글 번역본은 번역 상태를 모르기 때문에 잘 모르겠습니다만 괜찮을거라고 생각합니다.

이 책을 추천하는 이유는 다음과 같습니다.

1. 원래 2인자가 더 자세히 설명을 잘하는 법(?)
이상한 결론이지만 제 농담이 섞였습니다.

2. 긴 문장
한 문장이 3줄을 넘기는 설명의 장황함.

3. 더 많은 목차.
C++과 어쩔 수 없이 이야기 해야 하는 설계에 대한 이야기들

4. 흥미있는 예제들
사람에 따라서 다를 수 있습니다.

5. 믿을만한 저자
2인자

6. 프로그래머 취향(?)에 맞는 프론트 이미지
무인도에서 읽으라 이겁니다. (3nd)

7. 자매품(?)인 inside C++ object model과 C++ gems을 읽으며 즐거운 시간을 보내세요.
정말로 3권 모두 꼭 읽어보아야 할 책입니다.

조금 장난같지만 진지하게 저는 C++ Primer. 이 책을 추천합니다.

ps : 주의할 점은 역시나... 책이 오래되었기 때문에 현재의 컴파일러에서는 문제가 없는 부분을 긴 문장을 할애하여 설명하는 부분들이 꽤(?) 있다는 점입니다. 그 정도는 스스로 컴파일 해보면서 습득하세요. :)

이런 저런 불미스러운 일로 블로그 활동을 접은지 이제 8개월이 지났네요. 일전에 알고 지내던 분들과 연락도 끊겨서 맘 고생이 좀 많았습니다. 생각해보면 아무것도 아닌데 본인 스스로 사건을 더 크게 만든건 아닌가 하고 말입니다.

어쨋거나 이제 2009년 입니다. 2009년을 계기로 다시 블로그 활동을 하려고 합니다.

모두 새해 복 많이 받으세요. :^)