스테이트 기반 언어.

요즘 가끔 짜다가 잊는 것 중 하나가,
C++(대부분의 다른 랭규지도 마찬가지겠지만 일단 이거만 주로 했으니) 는 state 기반 언어라는 것입니다.

누구나 알고 있는 사실입니다만, 코딩을 할때는 잊기가 쉽습니다.;

함수 실행전과 실행후의 스테이트를 맞춰 주는 것이 꽤 중요하다는거지요!
특히나 중간에 에러가 나서 리턴을 할때는 앞에서 생성한 것들을 꼭 살랑살랑 지워주고 리턴.
Try/Catch 를 잘 써서 관리하면 좋겠지만,,,ㅎ

개발에서 사소한지만 중요한 것들

요즘 사소하지만 그냥 넘어가서 후회 했던 일들을 반성하면 몇가지 적어봅니다.
다음 번에 또 똑같은 문제를 겪지 않기 위해서 말입니다.

1. 빌드/테스트/커밋/CI 과정은 최대한 편하고 간단하게.

빌드는 언제든지 한번에 모든 걸 빌드/리빌드 가능한 스크립트가 있어야 합니다.
뭔가 이상하면 탁 리빌드 누르고, 차한잔또는 책한챕터 읽는게 최고이지요!!.

테스트는 처음부터 고려된 것이 마음 편하지만, 또 그게 쉽지는 않은 경우가 많아서 regression test 라도 반드시 있으면 좋은 거 같습니다.(한번버그 생기면 관련 테스트코드를 만들어서 고치고 남겨서 다음에는 자동으로 테스트 하도록)

커밋은 obj,ncb 파일이니 이상한 것들 안 딸려올라가도록 자동으로 세팅해두고, 혹시라도 올라가면 사용자에게 반드시 이메일을 주는 것이 좋은 듯 합니다. 지워주센..=_=

CI 는 대략 커밋하고 5분내에 리포트를 받을 수 있는 것이 좋은 거 같습니다. 이거 기다리는 게 오래 걸리면 이래저래 귀찮아지지요. 그리고 CI가 실패일때는 다른 사람이 커밋/업데이트하지 못하도록 간단하게라도 해두면 좋은 거 같습니다. 빌드 안되는 거 업데이트 받는 거처럼 개발 의욕을 꺾는 건 없지요;;ㅎㅎ

2. 개발자의 자유시간 확보.
하다보면 조금만 이렇게 하면 효율성이 확 좋아질 거 같은데 도저히 건드릴 수가 없는 부분이 있습니다. 상사가 개발한 부분이거나, 시간이 좀 걸린다거나 하는 부분 말이져.  개인의 이런 아이디어는 상당히 소중하다고 생각합니다. 결국 1%라도 효율이 좋아지도록 생각하면서 회사도 개인도 발전하는 거니까요. 그런 면에서 구글처럼 까지는 못하더라도, 일주일중 어느 정도 시간은 하고 싶은 쪽 하센!! 이런 게 좋은듯 합니다.

3. Think Hard!!
대충 생각하고 대충 짜보고 대충 컴파일 해보고 다시 수정하고, 되면 넘어가고, 이런 것처럼 위험한 코딩은 없다고 생각합니다. 당장은 별 무리 없겠지만, 일단 프로그래머 본인 자체에게 치명타입니다. 생각을 한만큼 코딩이 느는거니까요. 저도 한때는 코딩하기 싫어서 대충 저렇게 한적이 있었는데 버그나 구조적 불합리합은 둘째치고 실력이 오히려 줄고 있는듯한 느낌이 들 정도였습니다.(뭐 따로 공부를 안한면도 크겠지만요)
따라서 아무리 사소한 걸 짜더라도 깊이 생각하고, 좀 더 좋은 방법은 없는 지 고민하고, 좀 더 재미난 방법이 없는지도 고민하면서 프로그래밍의 깊이와 즐거움도 느끼고, 본인의 실력도 향상시키고, 더불어 남이 보기도 좋은 코드를 짜면 1석3조라고 생각합니다.!!!

4. 새로운 툴/언어 등의 적용
처음 플밍 시작할때는 누구나 새로운 툴,언어 또는 재미난 오픈소스를 좋아합니다만, 시간이 지날 수록 귀찮아집니다. 역설적으로 이는 현재 사용중인 언어와 툴을 너무 잘해서-ㅅ-편해져서 그렇지 않을까 싶습니다.(아직도 VS 6.0 쓰는데는 해킹쪽 빼곤 없겠지요? 전 2007년까지 봤습니다.;; ) 그러나 새로운 걸 배우기 귀찮아하는 순간 우리는 퇴보하는게 아닐 까 싶습니다. 끊임없이 코딩이 재밌고, 우리 코딩 열정의 아궁이에 남은 씨를 꺼트리지 않으려면, 새로운 걸 계속 배우는 게 중요하지 않을 까 싶습니다. 여기서도 보면 Quick Learner 를 상당히 중요시하는 거 같습니다.

최근에 읽은 책 2권

<이외수 - 황금비늘>

단숨에 읽게 만드는 매력적인 작품인듯 합니다.
약간의 판타지와 현실 비판도 재밌게 읽어졌습니다.
근데 좀 뭔가 밝고 희망찬 느낌의 책을 읽고 싶었는데 조금 아쉽습니다.
제목은 뭔가 엄청난 희망과 사랑이 가득할 거 같았거든요.ㅎㅎ
(그럴려면 무협/판타지를 읽어야 되는걸까요. 붕붕 슝슝 이제 내가 왕임. ㅋㅋ 이런거 -ㅁ-)

<화성에서 온 남자 금성에서 온 여자>

당연히 읽었는 지 알고 있었는데, 내용은 처음보는 거네요. 하도 인용이 많이 되서 읽었는지 알고 있었습니다.-ㅅ- 고전이든 명서든 꼭 직접 읽어봐야 된다는 걸 알게 해주는 책입니다.
작가의 통찰력이 대단한 거 같습니다. 뭐랄까요, 많이들 알고 있지만 실제로 책으로 써내긴 어려울 거 같은 것을 이렇게 재밌고 쉽게!!!! 이래서 어딜가나 이 책의 인용이 있는 건가봅니다.
암턴 열심히 보면서 저의 무지를 깨우쳐 가는 재미가 있습니다.

요즘은 해외의 시골에서 살다보니 뭔가 따로 할일이 많지 않습니다.
덕분에 사색과 책에 조금씩 빠져가고 있는 거 같습니다.

IME

잊을만 하면 IME 문제가 한번씩 나타나는데요.

이유인즉슨 IME는 WindowProcedure 에 예민해서 메시지를 못 받게 되는 경우가 이런 저런 이유로 생겨서 입니다.

따라서 SPY++ 를 적극 활용하면 대부분 쉽게 해결이 가능하기도 합니다.

스케일폼이 다 해준다고 해서 편하게 생각하고 있었는데, 결국 바인때마다 또 이런 문제가 생기는 거보면 공짜는 없는 거 같습니다.(게다가 매버전마다 곁들여지는 스케일폼의 사소한 버그는-ㅁ-).
뭐 훌륭한 미들웨어 입니다만, 한국인 플머 한명 뽑으면 안 생길만한 버그들이 늘 생기네요.ㅎㅎㅎ

좋은 회사란?

좋은 회사를 찾기에 앞서 좋은 직원이 되어야 겠습니다만^^.

간단힌 좋은 회사를 생각해 보면,

1.우선 직원의 아이디어를 적극 수용할 수 있는 회사,

즉 직원이 자유롭에 아이디어를 제출하고 현실화되는 것이 제일 중요한 거 아닐까 싶습니다.

(어딘가에서 읽었던 호텔 청소 직원에게 호텔 청소 비품을 사는 아이디어를 제출하게 하는?)

즉 실제 현장에서 일하는 사람이 아이디어를 만들고 그 아이디어를 위로 전달할 수 있고, 그것이 실제로 반영 되는 구조가 좋지 않을까 싶습니다. 위의 청소 예도 저걸로 직원들의 효율성이 엄청나게 증가했다는 걸 읽었습니다.

2. 일정시간 자유롭게 회사를 위해 일할 수 있는 회사.

그 유명한 구글의 업무시간의 20%는 자유를 들 수 있겠습니다.물론 아이디어를 제출하고 어느 정도 확인이 필요한 부분이기도 합니다만,

많은 경우에 실제로 어느 정도 시간을 투자해서 한 번 해두면 작업 효율이 대폭 증가할 만한 일들이 꽤 있습니다. 자유롭게 일하라고 하면 대부분 하고 싶은 걸 할텐데요 사실 회사 업무와 관련된 일중에 하고 싶은 걸 찾으라 하면, 결국 저렇게 효율성이 대폭 증가되는 부분이지 않을까 싶습니다.(제 생각에는,,,ㅎ)

3. 같이 발전해가는 걸 인지하는 것?

직원과 회사는 같이 발전해 가는 것이라고 생각합니다 어느 한쪽만 쭈욱 발전할 수도 없는 듯 하고요. 일례로 회사만 발전하면 직원은 떠나게 되고, 직원만 발전해도 또 쉬이 떠나게 됩니다.^^ 같이 발전하고 같이 움직이는 것, 근데 이건 뭐 생각처럼 쉽게 되지 않는 거 같습니다. 후우;;

뭐 이러쿵 저러쿵 해도 최고의 회사는 결국 우리 말단? 직원이 같이 만들어가는거겠지요~~라고 생각하고 있습니다.^^

게임 엔진 내의 글로벌 VS 지역화

스타크래프트 2 렌더링 문서를 보다보면 글로벌한 라이트는 그냥 포워드로 지역 라이트는 디퍼드로 처리했다는 이야기가 나옵니다. 지역적인 알파오브젝트를 포워드로 렌더링하는 건 이런 저런 디퍼드렌더링 문서에 제법 나오고요.
요즘 렌더링은 이렇게 글로벌한 부분과 지역적인 부분으로 많이 나눠지고 있는 거 같습니다.
쉐이더의 경우도 글로벌한 우버 쉐이더(큰 하나의 파일에 디파인으로 구분)와 지역적인 비쥬얼 쉐이더 에디터가 같이 쓰이는 경우가 있습니다.

덕분에 게임 하나에 이런 저런 렌더링 기법이 들어가고, 여러가지 쉐이더 형태도 들어가고 하는 거 같네요-ㅅ- 글로벌한 녀석은 빠른 녀석으로, 지역적인 녀석은 다양하게 대응할 수 있는 녀석으로,,ㅎㅎ

boost

여지껏 프로그래밍은 회사에서 집에선 책이라는 모토아래,
개인 프로젝트를 해본 적이 없습니다만,(쉬는 틈틈이 알바한적은 있습니다만,)
프로그래머의 길, 멘토에게 묻다 의 장난감 패턴을 본뒤로 집에서도 살살 프로젝트를 진행해야겠다는 생각을 하고 있습니다. 뭐 책만 보고 회사에서 프로젝트로 진행하지 않을 경우 다 잊어버리는 문제도 있구요(실제로 렌더링 집에서 공부한 것들은 대체적으로 현실감 잊게 와닿지 않고 있습니다.) - (기존 제 블로그개발 환경 구성 참고)

일단 소프트웨어적으로 실제로 해봐야 할 건,
1. 멀티쓰레드 개념 잡기 / 테스트 패턴 적용(테스트 주도까진 모르겠습니다만, 일단 테스트를 염두에 두는 코딩이 기본이 될 거 같습니다 - 테스트를 나중에 작성하는 건 고통스러우니까요-ㅅ-)

2. 기타 표준 라이브러리 제대로 사용.
    => 보통 게임 엔진은 stl / boost  와 거리감이 있는 듯 합니다.(콘솔 지원등의 이유가 있겠지요). 그래서 집에선 stl , boost(tr1,tr2? , 0x) 등의 C++ 표준 따라가기를 진행해야 할 거 같습니다. 이번에 저번에 메모리풀 등을 보면서 여러가지로 좀 더 봐야할 필요성도 느꼈구요.

일단 베이스 프로젝트를 만들어야 하니,
boost + google io stream + stl(or eastl) + debug(ignore 가능한 assert) + dump(에러리포트 포함) + log(level 단위) + google test + component(+object pool}
정도로 생각하고 있습니다. 쓰고나니까 많아 보입니다만 뭐 늘 많이 하던거니 금방되겠지요^^.

boost 에 flyweight 이 있던데 MMO를 예로 들더군요 관심있게 봐바야겠습니다. 이번 기회에 람다와 bind 도 좀 보구요~

메모리 !!

매일 매일 다른 걸 하고 있습니다.
오늘은 한번쯤은 만나게 되는 메모리.

어느 게임엔진이나 비슷합니다만,
메모리는 자체 얼로케이터를 사용하게 됩니다.
(물리 엔진이나 뭐 이것저것들 보면 대부분 자체 메모리 얼로케이터가 따로 있는 것을 볼 수 있습니다. 귀찮게시리요-ㅅ- 스케일폼도 따로 있었던듯; )

기본적인 인터페이스만 제공하는 new / delete 또는 malloc;;만으로는 불가능하니까 그렇겠지요?
참고 : http://jacking75.cafe24.com/Tip/AboutHeap.htm

오늘 생겼던 문제는 align 문제 였습니다. 물리나 시뮬레이션 같은 경우는 아무래도 SIMD(SSE?) 버전을 사용하기 마련이고,  16비트 align이 기본적으로 작동해야 하는 경우가 있더군요-ㅅ-(물론 그쪽 라이브러리 데이타를 사용할 경우이겠지요).

일단 제일 깔끔한 건
외부 라이브러리 데이타만 모아서 외부 라이브러리에서 제공하는 얼로케이터를 이용하는 할당 받고 사용하는 것이라고 생각합니다.
(이래서 클린 코드에서 무조건 인터페이스 만들라고 하는 듯 합니다;;; )

대략 코드상으로 생각해보면

3rdPartyPhysicsComponent
{
   MacroFor3rdPartyAllocator()
    property1 , property2
}

MyEngineComponent
{
  3rdPatyPhysicsComponent* data;
  my datas,,,
}

대략 이런 형태가 될 거 같습니다.

하지만 뭐 내쪽 컴포넌트에서 살짝 서드파티 컴포넌트를 붙여서 쓸 수도 있겠지요-_-;
암턴 이런 경우 때문에 메모리 얼로케이터는 엔진껄로 데이타는 서드파티 클래스 이런 경우가 생깁니다.

보통은 특별한 문제는 안 생깁니다만, SIMD 버전등을 사용해야 하는 경우라면, 16바이트 얼라인을 맞춰줘야 겠지요.

__declspec(align(16)) 하고 열심히 선언해주면 new/delete를 오버라이트 해주지 않았을 경우에는 문제가 없습니다.(내부적으로 어떻게 처리하는 지는 모르겠네요.)

오버라이드를 했을 경우에는 편안한 방법은 없는 거 같습니다.
일단 좀 찾아보니 얼라인이 필요한 클래스에서 new/delete를 따로 얼로케이트 하는 방법이 있네요

Class MyEntity : public BaseEntity, Allocater<16>
{
}

이런 형태로 하면 된다고 하는 군요.
뭐 전 매크로로 필요한 경우 디파인해서 쓰도록 했습니다.;;후우;;

요즘 시스템쪽 기초 공부하느라 정신이 없군요;
메모리 얼로케이션 1.5 기가 정도 넘어가면 불안해진다는 것도 알게 되었구요;
(이건 왜 그럴까요?--+)

클린코드 #3 - 서드파티 라이브러리 통합

클린 코드 책을 본 뒤로, 널 값으로 튕기는 버그들을 보면서 널을 다 없애버려야 되는데 하는 생각을 하고 있습니다. 널 리턴 없는 세상을 꿈꾸며,,

이제 막 서드파티를 어떻게 통합할지에 대한 장을 마쳤습니다.

상당히 재미난 서드파티 붙이기 아이디어였는데요.
일단 서드파티 공부는
문서 읽기->테스트 작성하며 살살 실제 공부->레이어 제작(내 입맛대로,,,)->내 어플은 레이어와 깔끔하게 통신.

이중에서 테스트 작성하면서 공부하라는 아이디어가 참 좋은 거 같습니다.
새로운 서드파티를 공부하는 것도 어렵고,
인테그레이션을 만드는 것도 어려운 일인데,
둘은 한꺼번에 하지 말라는 얘기지요^^.

저도 저렇게 한꺼번에 하다가 몇 번 고생한 기억이 있습니다. 그리고 새버전이 나올때마다 또 고생했지요;;;
저렇게 테스트를 작성해두면 새버전이 나와도 안심하고? 테스트 돌리고 버전에 맞춰서 테스트 성공시키면 깔끔하게 돌아갈 것이다...라는 느낌이네요^^.

일단 실제에 부딪히면 몇가지 더 문제가 있겠습니다만, 테스트 작성이 요새 유행하는 이유는 서드파티를 많이 써야 되는 환경에서 비롯되지 않을까 싶기도 합니다.

프로그래밍 패턴.

요즘 새삼 프로그래밍 패턴이 필수적으로 자리잡았다는 것을 느낄 수 있습니다.
최근에 사용했던 두 게임엔진도 공통적인 프로그래밍 패턴들을 살펴 볼 수 있어서 간단히 적어봅니다.

1. 컴포넌트/엔티티/이벤트 패턴을 이용하여 툴과 엔진이 교류하게됩니다.
    엔티티는 대략 컴포턴트들로 이루어져 있고, 컴포넌트 다시 프로퍼티와 함수(Behavior)로 이루어져있습니다.
    그리고 C# 툴에서 프로퍼티 그리드를 이용하여 작업하도록 되어있습니다.

2.  자체 RTTI 와 STL 그리고 스트링 시스템을 가지고 있습니다.
     이 부분은 콘솔에서 이점이 있지 않나 싶습니다.PC 에서만이라면 속도나 편리성 대신에 범용성이나 편리함을 제법 잃어버리는 거 같기도 합니다. 최근에 EA STL 이 공개되었으니 이부분도 좀 살펴보고 싶긴 하네요. 그래도 그냥 표준적으로 사용하는 STL 이 마음은 편한 거 같습니다. (이제 별로 쓸일이 없어서 잊어버리고 있습니다만, BOOST C++ 0x 니 하는 것들도 나오는데 말입니다--+)

3. 오브젝트들은 항상 자식 노드를 가지고 있을 수 있습니다. 꼬리에 꼬리를 무는 노드 구조입니다. 이걸 무슨패턴이라고 하던데요--기억이;;