Try & Error

public ref class MySingleton sealed
{
public:
	static MySingleton (void);

private:
	MySingleton (void);

public:
	static property MySingleton ^ mySingleton 

	{
		MySingleton ^ get()

		{
			return m_mySingleton;

		}
	}

private:
	static MySingleton ^ m_mySingleton;
};


출처 : mine



ref class MyClass {

    // If you use a getter for 'instance' you can avoid 'initonly' keyword
    static MyClass^ instance = gcnew MyClass();

public:
    ...

    static property MyClass^ Instance
    {
        MyClass^ get()
        {
            return instance;
        }
    }
    ...
};

출처 : http://www.ureader.com/msg/14523461.aspx

작년 11월 14일 KGC 2008에서 발표했던 강연의 문서입니다

[출처] [본문스크랩] [GameDev] KGC 2008 - C#을 사용한 빠른 툴 개발|작성자 구리구리

 어느 조직에서나 있을 법한 일이며, 이로 인해 정신적, 육체적으로 피해를 받기도하고 업무 진행에 방해가 되기도 한다.

결국 리더가 변하지 않으면 해결될 수 없는 문제이다.

 리더가 되었을 때 이런 실수를 하지 않기 위해서 꼭 읽어둘 필요가 있는 글

조직내침묵현상.pdf

 "d3dx9math.h"를 include할때 이전에 정의되어있는 'new'때문에 에러가 발생했다.

그렇다고 기본new를 그냥 undef하고 사용하기는 찝찝해서 아래와 같이 잠깐동안만 기본new를 undef하고

다시 선언하는 방법을 사용해 에러를 없앴다.

// 이전의 new를 저장했다 다시 디파인
#pragma push_macro("new") // 기본new를 저장
#undef new // 기본new를 삭제
#include "d3dx9math.h" // 이 파일에 같은 이름의 new 매크로가 존재
#pragma pop_macro("new") //  저장해둔 기본new를 로드

출처 : http://blog.naver.com/nkein82?Redirect=Log&logNo=100088967998

일전에 Dependency에 대한 고찰이라는 글로, Dependency의 종류와 xDepend 툴들을 소개한 적이 있습니다.

이번 POST는 윗 글의 연장선상으로 Dependency 를 해결하기 위한 올바른 설계 방법 몇가지를 소개하고자 합니다.

물론 재미난(?) 그래프로 여러분의 시스템의 Depedency를 파악하는 것을 보여드리고 싶지만..  모든 일에는 순서가 있는 법.  여러분이 와 닿는 그림과 코드로 간단히 설명드리도록 하겠습니다.

Dependency가 없는 상태로 시스템을 구축한다는 것은 불가능합니다. 재사용의 미덕이 바로 Dependency의 또다른 이름이기도 하죠.

어떻게 하면 Dependency를 잘 관리할수 있을까?  그 해답을 제시해주신  아키텍트를 소개하고자 합니다.

그 분은 바로 Object Mentor의 Robert C. Martin 입니다.  Clean Code의 저자로써 알려져 있지만, 사실 이것보다  이름을 더 크게 알리게 한 주역은 패턴의 5가지 법칙(OCP, DIP, LIP, ISP, SRP)입니다.

그런데 이 5원칙의 빛에 가려 숨겨진 Principle이 하나 있는데요.  이름하여 패키지 구조의 원칙들(Principles of Package Architecture) 입니다.

이 논문에서 Dependency를 깨거나 완화하는 방법들을 여러분에게 소개하고자 합니다.

1단계: Circular Depedency를 무너 뜨려라

Circular Dependency는 패키지 소프트웨어를 만드는 구조에서 꼭 피해야 되는 구조입니다. 바로 Change Propagation (변화 전파)이 체인을 이루어 구성될수 있기 때문입니다.

여러분의 모듈중 일부분에 변화를 가하면, 다른 것들이 연쇄적으로 체인과 같이 묶여 변화를 한다면 어떻게 될까요?   생각만 해도 무시무시한 일이죠. 결국 그래프를 이루는 모든 모듈에 대해서 검증(테스팅)을 해야 하는 문제가 발생합니다.

Robert C. Martin은 Circular Dependency를 끊는 방법으로 완충작용을 해줄 새로운 Package 생성 또는  Interface 를 통해 변화를 상쇄시키는 방법을권하고 있습니다.

개발자라면 누구나, Try.. Catch문을 걸어서 발생한 오류를 화면에 MessageBox로 뛰워 본 경험이 있을 겁니다.  이렇게 되면 바로 위 그림과 같은 Circular Dependency가 발생하게 됩니다.

이 그림은 통신 모듈에 필요한 에러사항들을 GUI 관련 모듈을 통해 출력하다 보니, 이 세가지가 연관성을 갖게 되는 것입니다.   이러한 관계를 끊기 위해서 Robert C. Martin은 아래와 같이 새로운 Package를 만드는 것을 권고하고 있습니다.

시스템에서 사용하는 모든 메세지(Error 메세지를 포함)를 관리하는 Manager를 별도로 두어,  GUI와 통신 모듈이 한 방향으로 Dependency를 구성해 Circular Dependency를 끊어 버린 경우입니다.

이런 상황에서는  Log4X (NET, J)처럼 Attribute(AOP) 이용해 기존 모듈에 영향을 최소화하거나,  Listener를 이용해 IoC를 구성하는 것도 좋은 방법입니다. (IoC는 뒷부분에서 언급하도록 하죠)

또 다른 형태의  Circular Dependency를 보도록 합시다.

이 것은  두 패키지를 구성하는 내부 모듈들간에  간접적인 Circular Dependency가 생겼습니다.  하지만 Interface를 통해서 완충 장치를 두어 해결한 경우입니다. 이건 그림을 보니 다 아실것이라 생각이 들어서 패스하도록 하죠 

2 단계: 무거운 Dependency를 깨뜨리는 무기, IoC (Inversion of Control)

무거운 Dependency라고 해서 읽으신 분이 의아해 하셨을 겁니다.  이 의미는 모듈간에 강력한 결합으로 인하여  쉽게 테스트하거나 확장하기 어려운  상황에 무거운(Heavy) Dependency라고 합니다.

또는 전에 언급했던 Implementation Dependency에서 특정 모듈이 없으면 아예 돌아가지도 않는 상황을 말하는 Hard Dependency라고 봐도 무방합니다.

이 소스 코드는 Tracer를 MessageQueue 로만 데이터를 추적할수 있기 때문에, Tracing이 어렵고 확장성 역시 떨어집니다.  MessageQueue에서 다른 형태로 출력을 하기 위해서는 결국 Tracer를 수정해야 되는 문제가 발생하죠.

그래서 IoC (Inversion of Control)을 적용하여, 다양한 방법으로 데이터를 추적할수 잇는 TraceListner를 아래와 같이 설계를 해봅시다.

소스에서 보이는 IoC의 핵심 키워드인 XXXListenr(TraceListener)를 통해서 MessageQueue외에도 File, XML과 같은 다양한 형태로 출력을 할수 있을뿐만 아니라, 확장성과 테스팅이 좀더 용이 하게 되었습니다.

3단계: NINJA가 도와 드려요! 한발더 Dependency Injection (NInject)

IoC를 이용하여 좀더 변화에 유연하며 확장 가능한 소스코드가  생성되었습니다.

하지만 FileListener를 XXXListener로 변경을 위해서는 소스 코드를 변경하거나 Metadata 형식 (Component Configurator)를 직접 구축해야 합니다.

이러한 문제점들을 한방에 해결해 줄수 있는 정보들을 실시간을 삽입,삭제 변경할수 있는 Dependency Injection Container가 나왔습니다.

Container를 통해서 이제 우리는 Dependency의 제어가 한결 더 쉬워졌습니다.

위 의 예를 잠시 이용해 볼까요?

출처 : http://arload.wordpress.com/2008/12/07/dependency_managment/

필자는, 임베디드 시스템 분야에서의 10여 년 간 개발자로 일하였으며, 개발 프로세스 개선 활동을 해 왔다.(소속 프로젝트의 SW-CMM Lv.2 달성 및 Panasonic Software Forum 2008에서 해외DC 대표로 사례 발표) 지금은, 게임 개발사의 품질보증부서의 프로세스 개선 파트에 근무 중이다.

게임 개발사에 입사한 직후 몸소 느낀 자유 분방한 분위기는 쇼크였다. 게임 개발사는 엔터테인먼트사업이라는 간판 아래 개인의 자유와 창의성을 중시하였다. 프로젝트 관리, 게임 디자인, 소프트웨어 개발, 아트 등의 분야가 집결되어  50여명이 넘는 개발 인력이 3년 이상의 개발 기간을 갖고 진행하는 게임 개발은, 프로젝트의 규모가 거대했다.

하지만, 필자가 1년 넘게 개발 프로세스 개선 활동을 느낀 점을 한 마디로 표현하면, '아쉽다' 였다. 이 말은, 개발 프로젝트(게임)의 성공 여부와 관계 없이 안타깝다라는 말이다.  더 쉽게 얘기하겠다. 개발비가 줄줄 센다는 것이다.

대규모의 개발조직에서, 10명 내외의 인원만이 게임 서버와 클라이언트의 개발을 담당한다. 종합 엔터테인먼트 제작 조직의 10여명이 IT개발자라는 얘기다. 10여명의 개발자의 손에서 만들어지는 제품(게임)은, 컨텐츠의 양과 스케일에 비해서 영세적인 것이 일반적이다. 일반적인 벤처기업의 프로젝트 개발 조직의 규모와 비슷하고, 개발 성숙도 또한, 1인 중심적인 체제이다. 카네기 멜론 대학에서 창안한 개발 성숙도 레벨을 빌어서 표현하자면, CMM Lv.1에 해당할 것이다. 모든 개발 노하우는 개발자의 머리 속에 있으며, 소스코드, 설계문서, 요구사항의 이력 및 변경점의 관리가 되고 있지 않다. 그로 인해, 핵심 개발자가 전직을 하거나, 불의의 사정으로 조직에서 이탈할 경우, 이를 매울 수 있는 조직의 프로세스가 준비되어 있지 않는 것이다. 신규 프로젝트를 준비함에 있어서도, 재활용 가능한 개발 자원이 없음으로 인해, 맨 땅에 헤딩을 하는 상황도 발생하게 된다.

이에 필자는 다음의 해결책을 제안한다.

"개발방법론? 스크럼? 기본에 충실하자"

많은 개발 조직이, 저명한 외부의 개발방법론을 적용하고 있다. NC소프트의 모 개발팀도 스크럼의 변형 적용을 하여 효과를 봤다는 얘기도 있다. 스크럼과 같은 익스트림 프로그래밍 류의 개발방법론은, 불필요한 문서화를 없애고, 여러 번의 반복(iteration)을 통해서 항시 실행 가능한 버전을 보완해나가는 방법이다. 작은 스프린터를 뛰면서 백로그를 활용함으로써 설계 변화에 재빠르게 대응할 수 있는 이 방법들은, 한 순간에 설계(게임 디자인)이 확 뒤 엎어 지기도 하는 기도 하는 게임 개발에 알맞을 것이다. 하지만, 여기서 간과되는 것이 있다. 필수 불가결의 문서는 반드시 작성하고 관리해야 하며, 소스코드 리뷰 및 모든 문제점의 관리되어야 한다는 것이다. 그리고, 모든 것은 조직의 프로세스라는 전제가 필요하다는 것이다.

(1) 조직 프로세스의 정의 및 적용

업무를 진행함에 있어서, 어떤 표준을 따르며, 단계 별로 필요한 행위 및 산출물을 정의하는 것을 말한다. 명확한 조직의 프로세스는, 구성원 개개인이, 자신의 지금 어떤 위치에서 어떤 업무를 해야 하는지를 상시 파악하고 인지할 수 있게 도와준다.

(2) 문서화

시스템 아키텍쳐, 게임 서버-클라이언트의 설계서, 기능 설계서, 버그 대응서, 리뷰/회의록, 요구사항 관리서 등이, 소프트웨어 개발자로써 반드시 작성을 해야 하는 필수 문서이다. 모든 문서는 최신 상황으로 갱신되고 이력이 관리되어야 한다. 간혹, 간단한 버그를 대응하는 경우, 담당자 만이 이해할 수 있는 단순한 수치 조절을 했다고 하자, 당사자가 아닌 다른 멤버가 관련 부분과 연관된 기능 개선을 하는 경우, 소스코드 만으로 시스템 구조를 파악해야 하는 난감하고 짜증나는 상황이 발생한다. 자신의 머리 속에 있는 지식을 모두 문서화할 수는 없겠지만, 구현된 시스템의 소스코드를 보다 값진 개발자원으로 만들고 활용하기 위해서는 문서화가 반드시 필요하다. 문서화가 되지 않는 소스코드는 자칫 아무짝에도 쓸모 없게 될 수 있다.

(3) 소스코드의 변경 관리

형상관리. 왜 갑자기 이 단어를 꺼냈는지 알 사람은 알 것이다. 많은 개발자들이 Visual Source Safe, SVN, CVS등의 형상관리 툴을 통해서 소스코드를 관리한다. 멤버가 수정한 파일, 변경 내용 등이 이 형상관리 툴을 통해서 알 수 있다. 하지만 요점은 단지 '알 수 있다'라는 것이다. 특정 부분(예를 들어, 게임 클라이언트로부터 수신한 네트워크 패킷의 파싱 처리를 하는 부분)의 변경 의도 및, 최적화 되어 있는 소스코드의 이력을 파악하려면, 각 리비전 마다의 변경 내용을 하나하나 체크하면서, 때로는 수정 후 원복 되는 부분과, 관련 수정 부분의 모든 소스코드를 하나하나 찾아가야 할 것이다. 대응을 했던 당사자라면 모를까, 제3자가 이런 작업을 하려면 많은 공수가 필요하다.

한 마디로 정리하겠다. 형상관리 툴은 단순히 버전을 관리하기 위한 툴이다. 파일의 변경 내용 비교 및 커멘트는 보너스이며 제한적으로 제공되는 것이다. 특정 시점의 버전을 취득하고, 때로는 버전의 롤백과 브랜치 관리를 한다. 소스코드의 변경점은, 소스코드 자체로 해야 한다. 한번 추가한 소스코드는 #ifdef 등으로 무효화는 할 수 있으나 절대로 삭제할 수 없다. 잘못된 소스코드도 소중한 이력이다. 변경된 소스코드는, 조직 프로세스에서 규정된 일정 표준에 의해서 누가, 언제, 왜, 어떤 문제점으로 인해서 수정을 했는가를 명기 해야 한다. 해당 수정 부분과 Problem List가 연계되면 더 없이 좋다.

(4) 변화 관리

변화관리는, 소스코드의 변경관리하고는 다른 말이다.  어떠한 수정을 함에 있어서, 그에 영향을 받는 부분을 사전에 분석해서 확인 및 관리를 하는 것을 말한다. 변화관리의 가장 쉬운 적용 예로, 대응 내용의 리뷰 시 파급 범위를 한정하고 확인하는 방법이 있다. 자신 외의 멤버에 의한 동료리뷰에서, 미처 발견 치 못한 사항을 부작용을 발견하기도 한다.

(5) Problem List

제품의 버그를 관리하는 Problem List로써, BTS(Bug Tracking System)의  사용이 정착화 되었다. 여러분은 BTS를 통해서, 버그를 등록하고 폐쇄까지를 관리하고 있다. 하지만, 이것은 제한적인 활용이다. 시스템 설계를 리뷰 할 때, 대응된 소스코드를 리뷰 할 때, 버그 대응서를 리뷰 할 때 발생한 지적 사항 또한, 발생부터 폐쇄까지 누락 없이 관리를 해야 한다. 이른바 리뷰 지적 사항이 그것이다. 이에, 개발과 관련된 모든 이슈를 Problem List에 등록하여 관리하는 적을 추천한다. BTS라는 이름에 얽매이지 말고 활용하자.

이상, 게임 개발 조직의 소프트웨어 개발자가 지켜야 하는 기본 사항들을 설명하였다.

이 다섯 가지 사항의 준수가 도저히 불가능하다고 어렵게 느껴진다면, 여러분은 너무 편하게 개발에 임했다고 말할 수 있다. 지금 여러분이 여러분의 조직의 개발활동이 편할 지라도, 후임자, 후임프로젝트, 조직, 회사는 그로 인해 공수를 할애하고 개발비를 쏟아 붇게 되는 것이다. 여러분이 개발한 자원은 다른 프로젝트에 도움을 주지 못하고 그 자체로써 똥이 될 수도 있다.

"나는 창의적인 게임 개발자니까, 자원의 재활용, 프로세스, 그런 거 신경 쓰지 않고 내 방식대로 할거야"라고 생각한다면 어쩔 수 없지만, 개발자로써 개발 프로세스의 적용 및 개선 활동을 리드 하였으며 그로 인해서 개선사항을 경험한 필자의 제안을 귀담아 들어 줬으면 한다.

게임 개발사의 소프트웨어 개발자 여러분, 여러분은 엔터테인먼트의 제작자가 아니다. 개발자로서 지킬 것을 지키자.

                                                  Actoz Soft Co., Ltd. > Quality Assurance > Process Improvement 김남훈

출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNo=28&no=246