게임 클라 개발

ECS 정의 "A different paradigm of writing code, where we model our programs in a data oriented way" 유니티 ECS 메뉴얼에서는 ECS를 위와 같이 정의했다. 데이터 지향 설계방식은 아래 글을 참고. https://tsyang.tistory.com/68 Data-oriented Design (데이터 지향 설계, DoD) CppCon 2014 - Mike Acton의 "Data-Oriented Design and C++"을 주로 참고해서 씀. https://www.youtube.com/watch?v=rX0ItVEVjHc 인트로 1. 소프트웨어는 플랫폼이다. 2. 코드는 실제 세계의 모델을 중심으로 설.. tsyang.tistory.c..

CppCon 2014 - Mike Acton의 "Data-Oriented Design and C++"을 주로 참고해서 씀. https://www.youtube.com/watch?v=rX0ItVEVjHc 인트로 1. 소프트웨어는 플랫폼이다. 2. 코드는 실제 세계의 모델을 중심으로 설계되어야 한다. 3. 코드는 데이터보다 중요하다. 저 위의 3가지 명제를 보면 그럴 듯 하다. 특히 2번의 경우에는, 게임 클라 개발자로써 많이 의식하는 명제인 것 같다. 누가 저렇게 하라고 시키지는 않았지만 많은 예제코드에서 저런 식으로 코드를 짜니까. (ex. 몬스터 클래스가 있고 그 안에 transform, status, animation... 등을 포함) 강연자인 Mike Acton은 저 위의 3가지 명제를 거짓말이라고..

개발을 하다 보면 외부 코드 (구매한 패키지, 오픈 소스, 다른 팀이 개발한 컴포넌트 등) 를 사용할 일이 있다. 이 장에서는 이런 외부코드를 깔끔하게 사용하는 법에 대해 다룬다. 외부 코드 사용 외부 인터페이스를 사용할 때는 해당 인터페이스를 사용하는 클래스 밖으로 인터페이스가 노출되지 않도록 해야한다. 만약 그렇지 않다면 다음과 같은 문제가 생긴다. 만약 외부 인터페이스의 메서드들이 모두 노출된 상태에서 사용한다면, 누군가 의도치 않은 메서드를 사용하여 예기치 않은 문제를 발생시킬 수 있다. 외부 인터페이스가 변할 경우, 메서드를 사용한 코드를 모두 수정해야 한다. 따라서 외부 코드를 새로운 클래스로 감싸거나 Adaptor 패턴을 이용하면 좋다. 이 경우 인터페이스에 변경이 발생해도 해당 클래스만 수..

깔끔한 오류 처리는 중요하다 여기 저기 흩어진 오류 처리 코드 때문에 코드의 가독성이 떨어질 수 있기 때문이다. 오류 코드보다 예외 예외처리가 아닌 오류 처리는 기본적으로 if,else 분기를 타며 Debug.Log(...)를 하는 코드이다. 그러나 이런식으로 쓰면 논리가 오류 처리 코드와 뒤섞여 알아보기 힘들다. 그러나 예외를 사용하면 이를 구분할 수 있다. 단, 앞 장에서 말했듯, 오류 처리도 '한 가지 일'이다. 오류를 처리하는 알고리즘은 분리해야 한다. public void DoSomething() { try { TryDoSomething(); } catch (Exception e) { } } Try-Catch-Finally 부터 작성해라 별 이유는 아니고 이렇게 하면 자연스럽게 try 블록의 트..

6장 - 객체와 자료 구조 흔히 필드를 private로 선언하고 getter, setter를 public으로 놓는데 이게 뭔 의미가 있을까? 저자인 로버트 C. 마틴도 `조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지는 않는다.` 라고 말한다. 그보다는 추상 인터페이스를 제공해야 한다고 말한다. 즉, 자료를 하나하나 공개하기보다는 추상적인 개념으로 묶어서 표현하는 것이 좋다. public interface FuelTank { double getFuelTankCapacity(); double getFuel(); } public interface FuelTank { double getPercentFuelRemaining(); } 즉, 위에꺼보다 아래꺼가 낫다. 개발자는 자료를 표현할 가장 좋은 방법을..

4장 주석 주석은 실패를 의미한다. 코드로 의도를 표현하지 못한 것을 만회하기 위해 주석을 사용한다. 즉, 원래는 주석 없이 코드로만 의도를 표현하는게 가장 이상적이다. 심지어 주석은 보통 나쁘다. 왜냐? 코드를 변경하면서 주석을 유지보수하기란 힘든 일이고, 결국 주석은 낡아지고 잘못된 정보를 드러내게 된다. 그럼에도 좋은 주석이 있다. 코드로 의도를 표현하는 것이 가장 이상적이지만 현실적으로는 힘든 경우가 많다. 다음은 좋은 주석의 예이다. 정보를 제공하는 주석 : 기본적으로는 함수나 변수의 이름에 정보를 담아야 한다. 그러나 시간을 나타내는 문자열의 포맷같은 정보는 유용할 수 있다. 의도를 설명하는 주석 : 프로그램의 의도가 아닌 코드를 작성한 저자의 의도는 타당하다. (저자의 의도를 코드에 담을 수..

로버트 C. 마틴의 클린코드 2,3장을 정리 이름(22p~) 이름은 의도를 분명히 밝혀야 한다. 이름을 보고 존재이유, 수행 기능, 사용 방법을 알 수 있어야 한다. 오해를 불러올 수 있는 이름은 피해라.(24p) 쓸데없는 단어 붙이지 마라 : ~Info, ~Data 이런게 무슨 정보를 제공하는가? customer, customerInfo, customerData 는 관례 없이는 구분하기 힘들다. 읽는 사람이 차이를 알도록 이름을 지어야 한다. Manager, Processor... 등 도 마찬가지 타입을 인코딩하지 마라 : monsterList 는 그냥 monsters로 해라. 타입이 Dict로 바뀌면 어쩔껀가? 타입을 적는다고 해서 이득도 없다. 'm_'이런 접두어도 붙이지 마라 : IDE에서 색 다..

로버트 C. 마틴의 클린 아키텍쳐를 읽고... 12장부터 '대충' 요약 컴포넌트 컴포넌트는 배포할 수 있는 가장 작은 단위를 의미한다. (jar, dll 같은 파일) 컴파일형 언어에서는 바이너리 파일의 결합체, 인터프리터형 언어의 경우 소스파일의 결합체이다. 잘 설계된 컴포넌트라면 반드시 독립적으로 배포가능(=독립적으로 개발가능)해야한다. 어떤 클래스를 어느 컴포넌트에 포함시켜야 할까? 세 가지 원칙을 고려할 수 있다. REP (재사용/릴리스 등가 원칙) : 재사용 단위는 릴리스 단위와 같다. CCP (공통 폐쇄 원칙) : SRP의 컴포넌트 버전. 서로 다른 이유로 변경되는 클래스는 서로 다른 컴포넌트로 분리해라! CRP (공통 재사용 원칙) : 컴포넌트 사용자들을 필요없는 것에 의존하도록 강요하지 마라..

SRP (단일 책임 원칙) 흔히 이걸 모듈이 단 하나의 일만을 해야 한다는 의미로 오인하기 쉬운데 그렇지 않다. (단, 함수는 단 하나의 일을 해야한다는 원칙이 있긴 한데 이건 설계원칙은 아니고 리팩토링할때나 쓰는 원칙) SRP의 진정한 의미는 '단일 모듈은 변경의 이유가 오직 하나뿐이어야 한다.' 이다. 다시 말하면 '단일 모듈은 그 모듈을 변경하려는 집단(액터)이 하나여야 한다.' 만약 한 집단의 수정사항을 반영한 것이 다른 집단의 작업에 영향을 끼칠 수 있다면 이것이 SRP를 위반한 사례라고 볼 수 있다. (이런 사례는 종종 형상관리툴에서 Merge를 발생시킨다.) 해결책은 무엇일까? 확실한 방법은 액터마다 데이터와 메서드를 분리하고 데이터는 별도의 클래스를 만들어 공유하는 방식이다. 그러나 이런 ..

패러다임 프로그래밍에도 패러다임이 있다. 구조적 프로그래밍 객체지향 프로그래밍 함수형 프로그래밍 프로그래밍 패러다임은 프로그래머가 무엇을 할 지가 아니라 무엇을 하면 안 되는지를 말해준다. 위의 3가지 규칙은 프로그래머에게 goto문, 함수 포인터, 할당문을 뺏는다. 구조적 프로그래밍 goto문은 프로그램의 모듈을 분해하는 것을 방해한다. 만약 모듈을 분해할 수 없다면 분할 정복 기법의 사용이나 각각의 모듈을 테스트 하는데 어려움이 있을 것이다. 구조적 프로그래밍은 goto문의 사용을 제한함으로써 프로그래밍에서 테스트 가능한 단위를 작게 만들어 낸다. 이렇게되면 프로그래머가 각각의 컴포넌트, 모듈...등을 쉽게 테스트할 수 있다. 객체 지향 프로그래밍 흔히 객체 지향 프로그래밍의 요소로 캡슐화, 상속, ..