Posted on 2008/12/11 02:20
Filed Under 작업일기:Log

Ubuntu Kung Fu: Tips, Tricks, Hints, and Hacks
- 귀여운 고양이 표지의 우분투 관련 서적 "Ubuntu Kung Fu" :) ,
Photo courtesy of The Pragmatic Bookshelf -

회사에서 일을 하다보면 가끔 부정적인 생각에 사로잡힌 개발자들을 많이(?) 볼 수 있다. 타 업체 또는 같은 회사의 다른 팀에서 괜찮은 게임을 만들어도 이 게임은 와우랑 똑같네, 저건 카스랑 똑같네 등... 단점을 보고 장점을 보는 것도 아닌 단점만! 보는 경향이 짙다.

개발도 마찬가지인데, 개발 도중에 문제가 발생하면 문제를 즉시하고 고쳐 나아가야 보다 나은 게임을 만들 수 있는 건 사실이지만 서로 헐뜯고 깎아내리는 것은 문제가 있다고 생각한다. 인터넷에 보면 연예인들에 대한 악성 댓글처럼 게임 개발자의 이런 사고방식이 너무 크게 존재한다. 이러한 시각은 개발자 자신뿐만 아니라 대한민국 게임 개발자 모두를 부정하는 행위로 어떤 면에서든 득이 될게 없다. 실제 개발자들은 자기 자신뿐 아니라 모두를 깎아 내린다. 그것이 환경적인 영향이든 뭐든...

이런 문제로 게임개발을 원하는 많은 수의 구직자가 막상 취업을 해서 일을 하면 개발에 대한 열정이 사그라지게 된다.(경험상;;) 게임분야의 신입 연봉이 타 업종에 비해 적은걸 알면서도 이쪽 분야에 취업하는 걸 보면, 무엇보다도 게임을 직접 만들어 보고 싶은 열정을 가지고 있기 때문일 것이다. 그러나 이번에 함께 일하던 동료 2명이 다른 직종으로 이직하는걸 보면서 문제가 상당히 심각하다는 걸 느끼게 되었다. 적어도 게임 매거진, 포털 사이트의 게임기자들은 아직까지 한국의 개발자들을 깎아 내리진 않는다. 그래서 요즘 인터넷서핑 중 게임 포털 사이트에 더 자주 들어가는 것 같다. :)
- 와일드 하트 인 아프리카의 박예진, Photo courtesy of SBS TV -

얼마 전에는 클라이언트 신입 개발자 면접에 팀장님과 함께 면접관으로 참석을 했다. 1년 전 면접자의 입장으로 면접을 볼 때가 생각이 났는데, 면접관으로서는 처음으로 같이 일할 사람을 보는 자리라서 그런지 무척 기대를 하게 되었다. 열정을 크게 가지고 있는 면접자를 보면서 지금 뽑았다가 나중에 후회하면 어쩌나 하는 생각이 들었다. 그냥 다른 일을 권유할 수도 없는 것이고... 조금은 숨쉴 수 있는 게임 프로그래머가 되고 싶다 :)

* 일에 대한 열정은 자기 자신만이 만드는 것은 아니다. 열정을 갖고 일을 할 수 있는 환경적인 요인이 상당히 크게 작용한다. 여러 책들을 보면 오랜 기간 성공한 회사와 그렇지 못한 회사의 환경적인 요소 차이는 상상 이상으로 컸다. 회사입장에서 정말로 좋은 제품을 만들고 싶다면 환경적인 요소를 보다 더 신경 썼으면 한다.

* 같은 팀이건 다른 팀이건 상대방과의 의견 조율 중에... 잘못된 개발 방식 또는 진행과 관련된 의견충돌은 반드시 존재할 수밖에 없다. 하지만 그것을 빌미로 자신의 단순한 악감정(개인적인 감정)을 첨부한 의견충돌은 자제해야 한다. 그것이 무엇이 되었든 근본으로 돌아가 올바른 개발방법에 대해서만 충실해야 할 것이다.
크리에이티브 커먼즈 라이센스
Creative Commons License
2008/12/11 02:20 2008/12/11 02:20

Posted on 2008/12/01 02:01
Filed Under 작업일기:Log

STL Map은 시퀀스 컨테이너(Sequence container)처럼 [ ] 연산자를 제공합니다. 중요한 점은 "C++ Standard Library 튜토리얼·레퍼런스(인포북, 니콜라이 M. 조슈티스)" 책에도 나와 있듯이 [ ] 연산자의 인덱스는 정수 값이 아니라 map의 key 이라는 것입니다. 이것을 정확하게 숙지하지 않고 잘못사용하면, 심각한 문제가 생길 수 있습니다. 아래는 [ ] 연산자를 잘못 사용한 코드의 예입니다.
[code]
// 커피 자판기를 하나 만들고, 판매할 커피를 추가합니다.
std::map<int, std::string> mapCoffeeMachine;

mapCoffeeMachine[0] = "Espresso";
mapCoffeeMachine[1] = "Macchiato";
mapCoffeeMachine[2] = "ConPana";
mapCoffeeMachine[3] = "Latte";
mapCoffeeMachine[4] = "Cappuccino";
mapCoffeeMachine[5] = "Mcha";
mapCoffeeMachine[6] = "Caramel";
mapCoffeeMachine[7] = "Americano";

// 생각을 해보니 라떼와 카푸치노는 제고가 없네요.
// 라떼와 카푸치노 버튼을 자판기에서 사용하지 않습니다.
mapCoffeeMachine.erase( 3 );
mapCoffeeMachine.erase( 4 );

...

// 한 구매자가 자판기 앞에서 돈을 넣고 아메리카노를 누릅니다.
for ( int i = 0; i < mapCoffeeMachine.size(); i++ )
{
    if ( mapCoffeeMachine[i] == "Americano" )
    {
        ... // 따끈따끈한 아메리카노 한잔이 나옵니다.!?
    }
}
[/code]

과연 구매자는 자판기에서 따뜻한 아메리카노 한잔을 뽑아 담배와 함께 커피한잔을 할 수 있을까요? 평생을 기다려도 아메리카노는 나오지 않습니다. 위의 코드는 [ ] 연산자의 인덱스를 정수 값으로 취급한 상당히 잘못된 코드입니다. 문제점은 크게 두 가지로 나뉠 수 있는데, 첫 번째는 size() 함수로 컨테이너의 크기를 구하면 제거된 3, 4번 키 값 때문에 사이즈가 6 이 됩니다. 그러므로 6, 7번 key 값은 아예 비교 대상이 안 됩니다. 커피를 마시러 온 사람은 메뉴를 보고 눌렀는데, 커피는 않나오고 동전이 반환된 꼴이 된 것입니다. 그러나 커피가 않나오는 것보다 더 큰 문제점이 있습니다. 바로 제거한 3, 4번 키 값의 내용이 == 동등 연산자를 통해 빈 value 값이 다시 추가가 된다는 점입니다. 컨테이너의 크기는 8이 되어 이제 커피메뉴에는 8개로 등장하는데, 아무것도 없는 메뉴가 자판기에서 눌러질 수 있다는 사실입니다. 커피가 들어있지 않는 빈 컵만 받게 되겠지요.

위에는 단순히 자판기로만 예를 들었지만 삭제한 내용이 다시 추가되는 문제점은 실제 개발 시에 큰 문제점을 가져올 수 있습니다. 특히 여러 명의 개발자가 작업을 할 경우 개발자 마다 서로 다른 작업방식으로 프로그램이 다운될 수도 있습니다. 이러한 문제점 때문에 컨테이너를 순회할 때는 반드시 반복자를 사용하는 게 필요합니다.



포이트리 로고
직원 할인으로 점심식사 후 거의 매일가는 서초동 포이트리 커피숍 :)
크리에이티브 커먼즈 라이센스
Creative Commons License
2008/12/01 02:01 2008/12/01 02:01

Posted on 2008/09/12 17:00
Filed Under 작업일기:Log

최근 UI 출력에 사용되는 컨트롤 개선작업을 진행하면서, 리팩토링시 중요한 점이 무엇일까 하는 궁금증이 생겼습니다. 리팩토링은 일반적으로 완성된 로직 또는 모듈의 성능을 높이고 유지보수를 쉽게 하려고 내부 소스코드를 정리하는 작업을 일컫습니다. 성능과 유지보수를 위한 사용 편의성 중 어느 것이 더 중요하다고 구분할 수는 없습니다. 성능은 기본이고 개발 편의성을 최고로 끌어올려야 올바른 리팩토링 아닐까 생각합니다. 아무리 성능이 좋아도 인터페이스를 실제로 사용하는 개발자 입장에서 활용하기가 까다로우면 그 개발자에게 득이 되는 건 없기 때문입니다.

- Refactoring 서문
리팩토링은 소프트웨어 시스템의 원래 기능은 그대로 두면서 내부의 구조를 개선하는 것을 의미한다. 그것은 버그의 가능성을 최소화하기 위해서 코드를 깔끔하게 정리하는 엄정한 방법이다. 한마디로 리팩토링을 한다는 것은 이미 작성된 코드의 설계를 나중에 개선하는 것이다.
- 임백준의 소프트웨어 산책 중
리팩토링은 새로운 코드를 만들면서 미래를 향해 나아가는 프로그래밍이 아니라, 이미 존재하는 코드를 부수면서 과거로 뛰어드는 프로그래밍이다. 마치 미래의 전쟁에서 승리하기 위해서 과거로 뛰어든 영화 터미네이터의 주인공처럼 프로그래머는 과거로 돌아가서 미래를 코딩한다. 그 때 그들의 손에 들린 무기가 바로 리팩토링이다.

툴을 이용한 리팩토링도 가능합니다. 마소의 "리팩토링을 통한 프로젝트 망치기"를 보면 툴 지원 없이 섣불리 리팩토링하지 말라는 내용이 나옵니다. 리팩토링으로 프로그램의 버그가 증가한다면 오히려 해가 되겠지요. C++ 리팩토링 툴로는 Visual Studio .Net 2003 버전을 지원하는 Ideat Solutions의 Ref++ 가 있고(현재 Ideat Solutions는 해체되어 더 이상 새로운 버전을 출시하지 않습니다.), 개발자들이 많이 사용하는 Whole Tomato의 Visual Assist X 에도 리팩토링 기능이 따로 존재합니다. Visual Studio .Net 2005 버전에 무료로 사용 가능한 Refactor! 도 있습니다. Visual Assist에서 사용 가능한 리팩토링 기능으로는 이름 변경(Rename), 함수 추출(Extract Method), 필드 캡슐화(Encapsulate Field), 시그너처 변경(Change Signature), 소스파일로 함수 정의부 이동(Move Implementation to Source File), 멤버 함수 / 변수 추가(Add Member), 유사 멤버 함수 / 변수 추가(Add Similar Member), 함수 주석(Document Method), 함수 선언부 생성(Create Declaration), 함수 정의부 생성(Create Implementation) 등의 있습니다. 반복적인 작업을 수월하게 하는 데 도움이 됩니다.

사용자 삽입 이미지사용자 삽입 이미지
Steam 프로젝트의 파일 입출력 모듈 리팩토링, Photo courtesy of Gamasutra, Valve

리팩토링에 있어서 최종 버전이라는 건 있을 수 없습니다. 보통 성공한 온라인 게임의 수명이 10년을 넘기게 되는데, 소스코드가 너무나 완벽해서 10년 넘게 리팩토링 할 내용이 없다는 것은 있을 수 없는 일입니다.


관련 사이트

임백준의 소프트웨어 산책 - 3장 리팩토링 이야기, 임백준
마이크로 소프트웨어 - 2003년 9월호 리팩토링을 통한 프로젝트 망치기(?), 이복연
Refactoring - 마틴 파울러
크리에이티브 커먼즈 라이센스
Creative Commons License
2008/09/12 17:00 2008/09/12 17:00

Posted on 2008/09/01 22:07
Filed Under 작업일기:Log

과거와 미래보다 바로 지금, Now! 현재가 가장 중요하다는 생각으로, 차드 파울러의 실천사항 중 하나인 개발 일기 작성을 시작합니다. 개발 일기는 특별히 잘 써야겠다는 생각보다는 그날그날의 작업 내용 또는 앞으로 필요한 내용 위주로 짤막하게 적을 생각입니다.

사용자 삽입 이미지
UML 모델링 툴로 오픈소스 프로젝트인 StarUML 이 있습니다. 이전에 MS Visio 의 리버스 엔지니어링 기능으로 Visual Studio 솔루션에 포함된 클래스를 UML 다이얼 그램으로 뽑아 본 적이 있는데, 각 클래스별 상태 확인은 수월하나 클래스 간의 관계도를 확인하기가 어려웠습니다. StarUML 은 비록 오픈소스라 상용 UML 툴에 비해 기능이 부족할지 모르겠지만 클래스 간의 관계도를 한눈에 보기 쉽도록 잘 뽑아줍니다. 특정 프로젝트 소스를 분석할 때 도움이 되지 않을까 생각합니다. 한번 설치해서 사용해 봐야 할 유용한 툴입니다.

Visual Studio Team System에 대한 Microsoft 사의 세미나를 들었습니다. 형상관리와 관련하여 버그 리포트 확인과 수정한 소스에 대한 커밋을 동시에 진행하는 게 인상적이었습니다. 현재 저희 팀에서는 SVN 과 Mantis를 사용합니다. 사실 이슈 트래킹이 잘 안되어 있어서 이슈 추적이 어려운데, Trac 을 요긴하게 활용하면 괜찮을 듯합니다. 사내에서 Mantis를 사용하기 때문에 Trac 를 따로 또 사용하는 건 버그 관리 기능이 중복되는 문제가 있긴 합니다. 또한, 프로파일링이나 튜닝 등과 관련돼서 여러 가지 기능을 Visual Studio 하나로 다 처리할 수 있는데, 실제 활용도 측면에서 어느 정도 효율이 있는지는 직접 써보지 않고는 모를 일입니다. :)

크리에이티브 커먼즈 라이센스
Creative Commons License
2008/09/01 22:07 2008/09/01 22:07

About

by 외계고양이

Counter

· Total
: 56673
· Today
: 21
· Yesterday
: 34