가상의 온라인 게임으로 살펴보는
This presentation is the property of its rightful owner.
Sponsored Links
1 / 37

가상의 온라인 게임으로 살펴보는 리팩토링의 솔직한 이야기 PowerPoint PPT Presentation


  • 84 Views
  • Uploaded on
  • Presentation posted in: General

가상의 온라인 게임으로 살펴보는 리팩토링의 솔직한 이야기. 2008.11.14 김익중 2008 (R) http://rhea.pe.kr/. Contents. 가상의 온라인 게임으로 살펴보는 리팩토링의 솔직한 이야기 1) 일러두기 2) 리팩토링 3) 가상의 온라인 게임 NEMO Online 4) NEMO Online 제작기 5) 개발 중 리팩토링 6) 실패 사례 분석 7) NEMO Online 리팩토링 8) 배포 9) 반성하기 10) 결론. 일러두기.

Download Presentation

가상의 온라인 게임으로 살펴보는 리팩토링의 솔직한 이야기

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


5942948

가상의 온라인 게임으로 살펴보는리팩토링의 솔직한 이야기

2008.11.14

김익중 2008 (R)

http://rhea.pe.kr/


Contents

Contents

가상의 온라인 게임으로 살펴보는

리팩토링의 솔직한 이야기

1) 일러두기

2) 리팩토링

3) 가상의 온라인 게임 NEMO Online

4) NEMO Online 제작기

5) 개발 중 리팩토링

6) 실패 사례 분석

7) NEMO Online 리팩토링

8) 배포

9) 반성하기

10) 결론


5942948

일러두기

  • 우리 나라의 온라인/네트워크 게임의 특징

  • 중박(?) 이상의 힛트를 치긴 무척 힘들다

  • 한번 히트를 친 게임은 쉽게 스테디셀러 게임이 된다

  • 온라인 게임의 특성상 스테디 셀러가 된 이후에도

  • 꾸준한 업데이트가 필요하다.


5942948

리팩토링

  • 리팩토링이란? (from 위키백과)

  • 소프트웨어 공학에서 리팩토링(refactoring)은 주로 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다.

  • 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다.

  • 사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.

  • 왜 리팩토링에 관심을 가져야 하는가?

    • 원래 SI 쪽이나 오랜 시간 version up 을 해온 해외 애플리케이션들만의 영역

    • 몇 년 사이 한국의 온라인 게임들에게 필수적인 상황이 되었음

    • 80:20 법칙은 게임 개발에도 통한다

    • 이제까지 80%는 기존 코드에 대한 추가/업데이트였으며

      전혀 새로운 코드로 채우는 것은 20%에 불과하였다.


5942948

리팩토링

  • 리팩토링이 필요할때는?

  • 코드가 유지보수하기 힘들어졌을때

  • 몇년간 서비스를 지속하는 게임에서만 일어나는 과정이 아님

  • 신규 게임 제작을 하더라도 기존 라이브러리는 반드시 참조/이용하게 됨

  • 결국 소스 코드의 생명력은 게임 생명 주기보다 훨씬 길어지게 됨

  • 리팩토링은 항상 해야만 하는 것(애자일 개발)

  • 개발 완료후 유지보수 단계에서만 일어나는 일이 아니다

  • 잘못된 생각 :

  • "이 게임은 시장에서 딱 2년만 서비스하면 되는 것이거든요? 그러니까 그런거 신경쓸 필요는 없어요."


5942948

리팩토링

  • 리팩토링이 자주 발생하는 프로그램은?

  • 특정 영역사이의 브릿지 프로그램

  • 특정 클래스 사이의 브릿지 클래스

  • 특정 담당자가 없는 프로그램

  • 서로 다른 팀업무 사이에 놓인 프로그램

  • → 한마디로 만만한 프로그램


Nemo online

가상의 온라인 게임 NEMO Online

  • 가상의 온라인 게임 "NEMO Online"

  • 개발 시작은 2003년 무렵

  • 게임의 특징

  • 풀스크린일 경우 4:3 모니터와 16:9 모니터에 알맞게 최적화

  • 윈도우 모드에서는 리사이즈 가능 및 UI 구성요소 재배치

  • 로비에서 대부분의 정보는 리스트 컨트롤 형태로 제작

  • 게임 중에도 로비에 위치한 유저와 통신 및 100% 동일한 기능을 사용할수 있어야 한다

  • 다중 세션의 허용 - 한 클라이언트에서 동시에 플레이어를 2개 이상 배치가능

  • 서버 구분 없음 - 접속자가 늘게 되면 서버를 구분할려고 기획함

  • CPU 대전 지원


Nemo online1

가상의 온라인 게임 NEMO Online

  • 코드의 특징

  • 개발자라면 누구나 '잘' 만들려고 한다.

  • 개발자는 소스 코드내 동일함수의 이중 코딩을 엄격히 제한

  • C++의 폴리모피즘과 인터페이스의 철저한 사용

  • 자주 사용하게 될 기능은 전부 Static Library로 구성

  • 모든 자료구조는 STL만을 이용함(Map, List, Vector 등...)

  • 게임 사이트내 표준 UI, 표준 요구사항을 기존 플랫폼이 아닌 호환성 있는 독자적인 플랫폼으로 재구성

  • 유니코드

  • Win98에서도 작동가능

  • 개발중 수시로 리팩토링을 시도함


Nemo online2

NEMO Online 제작기

  • 세션 클래스

  • 로긴 이후사용자 정보를 유지하는 기본 클래스 생성

  • 세션정보가 필요한 모든 구성요소는 세션 클래스에서 상속

  • 실제로 엄청난 분량의 다중상속들로 구현


Nemo online3

NEMO Online 제작기

  • 전체 사용자 정보를 유지

  • 클라이언트는 RAM이 많고 인터넷도 빠르므로 모든 정보를 갖고 있자.

  • 서버에게 상세 정보 요청을 하지 않는다.

  • 로비 혹은 게임의 어느 위치에 있던 접속된 모든 사용자 정보를 생성, 업데이트, 삭제

  • 이로 인해 빠른 위치(Zone) 이동 가능

  • 전체 사용자 정보 클래스에서 상속을 이용하여 세분화된 사용자 정보 클래스 구현 (전체정보, 게임정보, 사이트 공통 정보, 친구 정보, etc...)

  • 싱글턴 패턴으로 전역변수화 시킴

  • 모든 정보는 리스트화 시켜 표현

  • UI 리스트는 팩토리 패턴 이용


Nemo online4

NEMO Online 제작기

  • 전체 화면시 모니터 해상도 비율

  • 4:3과 16:9 에서 각각 UI 구성요소가 다름

  • 16:9 로비에서는 사용자 정보 리스트가 추가됨

  • 화면을 구성하는 추상 인터페이스 선언

  • 인터페이스를 상속 받아 해상도 비율에 따른 독립적인 UI 구성


Nemo online5

NEMO Online 제작기

  • 리사이즈

  • 리사이즈시 필요한 정보(창의 너비, 높이)를 위해 각각의 가상 윈도우 개념을 도입

  • 전체 윈도우 사이즈를 기반으로 WM_SIZE를 이용하여 구성

  • 가상 윈도우는 GDI 정보와 D3D 를 기반으로한 모든 컨트롤 형태를 지원

  • 가상 윈도우는 전체 게임 화면에서 차지하는 퍼센트(%) 비율로 위치를 구함


Nemo online6

NEMO Online 제작기

  • 로비는 하나로 통일

  • 네트워크 구조는 밸런싱 서버를 거쳐 로비 서버로 접속

  • 게임서버와 로비 서버로의 이동은 서버 사이드내에서 발생

  • 클라이언트/서버 관게에서 접속과 해제는 오로지 로비 서버뿐.

  • 게임 중에도 로비에서 발생하는 모든 정보를 받음

  • 친구찾기, 위치추적(따라가기) 가능

  • 대게의 경우 로비와 게임은 다른 프로젝트로 구성되는 사례가 많음

  • 로비와 게임의 통신방법은 소켓, FileMap 등 다양


Nemo online7

NEMO Online 제작기

  • 게임룰

  • 템플릿을 이용한 Generic Algorithm으로 구현

  • 게임룰은 결코 변경되지 않을 것이라 가정했음

  • 외부 데이터 관리

  • INI 파일 – 초기 데모용 데이터 관리방법을 그대로 사용함

  • 자체 스크립트 언어


5942948

개발 중 리팩토링

  • 상기의 사항들로 제작도중일차적으로 개발자를 괴롭힌 것은 빌드 시간

  • STL의 빌드문제

  • 매크로 - 가상 윈도우 시스템, 운영체제 구별용 전처리기

  • 추상 인터페이스와 상속

  • 세션클래스들의 일반 상속

  • 개발도중 우선 적용했던 해결책

  • CImpl 패턴사용

    • Visual AssistX가 심볼을 찾지 못함

  • 헤더파일의 엄격한 참조검사

    • 별 도움이 안됨


5942948

개발 중 리팩토링

  • Win98문제

  • INI 파일의 한계가 64KB – 서비스중 데이터 로더 재작성

  • 유니코드 문제 – IncrediBuild 빌드 불가능

  • 대부분 전처리기(#ifdef)로 해결


5942948

실패 사례 분석

  • 개발자 입장에서 결코 성공적인 아웃풋으로 만들어 내지는 못함

  • 보통은 기능추가 중 프로젝트가 망가지게 되나,

  • NEMO Online의 사례는…

    • 지독히 이해하기 힘든 소스문제

    • 리팩토링 도중 디자인 패턴을 위한 디자인 패턴의 사용

    • 강박적인 일반화 사용과 의미없는 폴리모피즘

    • 세션 윈도우와 가상 윈도우의 디버깅 난이도

    • 빌드 시간


5942948

실패 사례 분석

  • 세션 클래스

  • 세션 클래스를 상속받은 클래스들은 결국 UI 클래스

  • 결국 세션 정보와 UI가 한 인스턴스로 합쳐짐

  • 데이터와 UI가 분리되지 못하는 결과를 초래

  • 리스너 구조의 범람으로 전혀 상관없는 모든 인스턴스에게 정보를 전달

  • 성능 및 디버깅에 악영향

  • UI가 합쳐지며 전체적인 성능은 극도로 나빠짐

  • 세션 클래스의 설계는 서버 개발자의 아이디어

  • UI가 붙은 코드를 평소 접해보지 못했음


5942948

실패 사례 분석

  • 사용자 정보

  • 서버가 분리되지 않은채 전체 사용자 정보를 담고 있어 클라이언트 성능에 악영향

  • 사용자 정보를 추상 인터페이스를 바탕으로 상속받아 변경시 너무 많은 수정을 요구

  • 초기 커넥션시 약 3MB 분량의 사용자 정보를 소켓으로 받음

  • 아무리 클라이언트 환경이 빨라졌어도 상기의 시도는 시기상조였음

  • 모니터 해상도 비율

  • 인터페이스 상속에 따른 구현의 이중성

  • 굳히 인터페이스 상속을 통해 구현해야 했을까?


5942948

실패 사례 분석

  • 리사이즈

  • UI 배치 수정에 악영향

  • 특히 모서리에 라운딩 처리가 된 UI 구현시, 일정 초과의 주범

  • 1px 가상 윈도우들로 간격조절

  • 너무 많은 UI클래스들을 생성시킴

  • 로비

  • 채널변경은 필수적은 기능

  • 초기 기획에 채널 변동이 없었더라도 채널 변경을 고려한 설계가 있었어야 했음

  • 전체 정보를 송수신하는 이유로 서버 성능 저하 초래

  • 네트워크 게임의 기본을 망각한 사례

  • 보이지 않는 것은 그리지 않고들리지 않는 것은 듣지 않는다


5942948

실패 사례 분석

  • 일반화된 게임룰

  • STL과 템플릿을 이용한 코드는 누구나 만들수 있다

  • 개발자의 겉멋이 프로젝트를 망치게 하는 대표적인 사례

  • 일반화 코드는 예외상향 변경시 의미가 없어진다

  • 게임의 룰은 반드시 바뀐다

  • 아이템은 게임룰을 바꾸는 대표적인 사례

  • CPU 대전과 실제 접속자들과의 대전에서 문제 발생

  • 약간의 변동이 생길때마다 두 부분의 룰을 고침


5942948

실패 사례 분석

  • 엄격한 헤더파일 구분

  • 네트워크 패킷 클래스에도 적용

  • 네트워크 패킷 구분화로 헤더파일의 재정의하는 사례가 생김

  • 서버와 다른 define을 사용하는 데이터 발생

  • 외부 데이터 관리 포맷

  • 외부 자료 관리 구조는 누구나 만들수 있지만 200~300개 정도의 자료를 다루게 되면 지옥이 된다

  • 검증툴이 반드시 필요

  • 웹브라우저처럼 “새로고침”을 할수 있는 기능이 필요


5942948

실패 사례 분석

  • Static Library

  • 왜 라이브러리를 만드는가?

  • 함수 기준으로 라이브러리로 만드는 것은 아무런 의미가 없다

  • 라이브러리 코드에 절대 컨텐츠 코드가 포함되어서는 안된다.

  • 라이브러리에 컨텐츠 코드가 포함되는 순간 그 라이브러리는 의미가 없다

  • 라이브러리를 만들기는 쉬워도 재활용은 정말 어렵다

  • 솔루션에서 라이브러리 프로젝트는 빨리 없애버려라


Nemo online8

NEMO Online 리팩토링

  • Re리팩토링 시작 (2007~2008)

  • 시대가 바뀌어도 여전히 개발자가 믿을 것은 OOP이다

  • 캡슐화

    • 클래스를 추상클래스로 만들고 전달값을 클래스의 파생클래스로 만들자

  • 상속

    • virtual 함수

  • 다형성

    • 각각의 virtual 함수들을 추상클래스의 이름으로 작동시키자


Nemo online9

NEMO Online 리팩토링

  • 기본 원칙

  • 변수는 ADT(abstract data type)를 사용하자

  • 함수호출은 폴리모피즘을 활용한 Plug-In을 이용하자

    • DLL 구조로 변경

  • 규정된 Plug-In으로 호출되지 않는 일반 함수는 오버로딩 금지

  • ConnectToServer(☺☺☺…)

  • ConnectToServer(♠♠♠)

  • ConnectToServier_Web_DebugOn()

  • ConnectToServier_Local_DebugOff()

  • ......


Nemo online10

NEMO Online 리팩토링

  • 컨텐츠 코드와 라이브러리 코드는 각각 다른 EXE, LIB, DLL로 구현해야 한다

  • UI와 자료구조는 절대로 한 클래스 속에 혼합되어서는 안된다

  • "자주 사용하는 기능" 이 아닌 컨텐츠와의 분리

  • 리소스를 절대 실행 파일 내에 두지 말것

    • 깨어진 유리창의 시작이 된다

  • 갓 졸업한 신규입사자가 와도 매주 컨텐츠를 뜯어 고칠수 있어야 한다.

  • 스크립트에 지나친 의존을 하지 않는다

    • 기획자, 디자이너가 작업하지 않으면 의미가 없다


Nemo online11

NEMO Online 리팩토링

  • 세션윈도우

  • 무분별한 상속과 다중상속 대신 포함을 고려함

  • 상속에 대한 정답은 1997년에 COM이 나오며 다 나왔다.

  • 가상 윈도우 갯수 줄이기

  • 대부분의 컨트롤들은 그림 장난으로 충분하다

  • UI 요소에 지나친 개체지향은 금물

  • 진행바같은 것은 StrechBlt 로 충분


Nemo online12

NEMO Online 리팩토링

  • 사용자 정보

  • 리팩토링 과정에서 기획 리뉴얼로 채널을 구분하게 됨

  • 사용자 정보의 수는 줄어들었으나 여전히 리팩토링의 대상임

  • 게임 중에는 로비에 있는 사용자 정보를 받지 않기로 함

  • 기획과 밀접한 관련이 있음

  • 위치상 떨어진 사용자들의 변경 정보는 시간 간격으로 모아서 전송

  • 리사이즈

  • 사이즈 정보의 리스너 / 옵저버 패턴으로 구현


Nemo online13

NEMO Online 리팩토링

  • 모니터 해상도

  • 4:3 과 16:9라도 UI구성을 통일시킴

  • 추상 인터페이스와 상속 자체가 무의미해짐

  • 추상 인터페이스 의미 자체가 사라졌지만 아직 UI 구성 추상인터페이스를 없애지 못함

  • 추상 인터페이스 제거 비용이 너무 큼

    • 앞으로의 연구과제

  • 현재 여전히 UI를 변경시킬때는 인터페이스 작업부터 들어가야 함


Nemo online14

NEMO Online 리팩토링

  • 게임룰

  • 좋은 사례란 알고리즘(구현)의 재활용이 아니라 인터페이스의 재활용이다.

  • CPU 대전과 네트워크 대전

  • 네트워크 패킷을 재활용

  • CPU 대전과 네트워크 대전을 동일한 패킷 전송으로 구현

  • 함수 Call 과 send()/recv()

  • 천재적인 코드를 만들지 말라

  • 섣부른 일반화를 적용시키지 말것

  • 이 세상은 일반화 시키기에는 달라지는 것들이 너무나 많다.

  • 100% 일반화가 가능한 게임은 테트리스의 행렬변환 뿐이다.

  • 특히 UI의 일반화는 디자이너와 전쟁을 유발시킨다.


Nemo online15

NEMO Online 리팩토링

  • 네트워크 개발자를 괴롭히는 것들

  • 빈번한 추가사항

  • 프로모션, 로비 배너, 방생성 옵션, 아이템, 리스트 정렬....

  • 게임 서버를 경유하지 않도록 수정

  • 웹서버와 WinINET의 활용

  • 파일 쓰기를 제외한 모든 툴(주로 DB에 툴)은 웹언어로 작성하는 것이 가장 효율적

  • 아이템툴, 밸런싱

  • 기획자, 디자이너의 영역으로 완전 이동

  • 보안이 중요하지 않은 데이터라면 HTTP 이용

  • 단 TRACE같은 것을 남겨서는 안됨


Nemo online16

NEMO Online 리팩토링

  • 더미 클라이언트

  • 누가 사용하는가?

  • 누가 기능별로 매시간 테스트하는가?

  • 게임은 단위 테스트 적용이 힘든 프로젝트

  • TDD툴로 활용할 수 있음

  • 스크립트 지원이 되는 더미 클라이언트는 100명의 QA가 부럽지 않다.

  • 더미 클라이언트는 서버와 첫 Connect 할 시점부터 꾸준히 함께 만들어야 한다

  • 디버그/릴리즈를 구분하지 않고 웹에서 실행이 아닌 직접 실행 시킬수 있는 방법을 만들어야 한다.

  • 퇴근시 실서버에 클라이언트 접속 해두기

  • 소스분석이 곤란할 경우 WM_COPYDATA로 작동하는 로봇을 만듦


Nemo online17

NEMO Online 리팩토링

  • 코딩

  • 주석을 사용하지 말것

  • 주석이 필요하다면 이미 잘못 만든 코드이다.

  • 대부분의 주석은 본인에게도 의미가 없다.

  • 주석처리한 코드를 다시 분석하는 일은 없다. 당장 지워버려라

  • 주석 대신 빌드중 메시지 출력을 활용

  • 좋은 소스코드란 개발자에게 소설처럼 읽혀야 한다.


5942948

배포

  • 디자인 결과에 따라 파일 구조가 달라진다

  • 런처와다운로드는 리팩토링의 결과에 따라 함께 설계가 달라져야 한다.

  • 게임 사이트라면 다운로더는 다양한 파일구성 타입의 게임을 런칭

  • 만만한 레이어?

  • 사실 가장 많은 리팩토링이 필요로 하는 부분은 배포과정이다

  • 클라이언트와 서버가 편하기 위해 배포과정을 더럽히지 말라

  • 보안 프로그램이나 백그라운드 실행기는 클라이언트가 직접 하는 것이 옳다

  • 각 회사마다 전설?

    • 로긴, 배포, 게임실행, 삭제 과정을 전부 이해하는 개발자가 없다


Nemo online18

Nemo Online 반성하기

  • 개발자스러운 삽질

  • 있는 것 다시 만들기, 보다 그럴싸 하게 만들기…

  • 보통 리팩토링 요구사항이 발생하는 이유는 끊임없는 기능 추가 단계에서다.

  • Nemo Online은 디자인 패턴을 활용한 리팩토링 자체에 의미를 두었다.

  • 개발중의 리팩토링은 권장하나 자체가 목적이 되어선 안된다.

  • 코드를 리팩토링하는 수단으로써 디자인 패턴

  • 그럼 디자인 패턴을 리팩토링하는 것은?

  • 극단적인 패턴추구가 정답은 아니다

  • C++ 코딩 재미에 빠져 목표를 잃었다


5942948

결론

  • 패키지 게임이 아닌 이상 리팩토링이 끝나는 시점은 없다

  • 패키지 게임이라도 라이브러리는 다시 리팩토링이 되어야 한다

  • 쉽고 단순하게 만들라

  • 디자인 패턴의 남용을 의심하라

  • 제네릭 프로그래밍이 타당한지 의심하라

  • 컨텐츠와 라이브러리는 절대 만나서는 안된다.

  • 라이브러리에 코드 욕심을 부려라

  • 컨텐츠 코딩은 딱 Visual C++ 바이블 수준이 최선의 코드이다.

  • 그 한계에 대한 조율이 좋은 유지보수하기 좋은 상태로 유지시킨다


Nemo online19

NEMO Online 리팩토링

  • Q/A


  • Login