[📚정보] [팁] 리팩토링이나 코드구조보다 더 중요한것 알려줄께

[40살개발자(182.224)]

나도 아름다운 코드를 짜고싶어서 디자인패턴에 심취한적이 있었어

뭐 유사품으로는 리팩토링 , 클린 아키텍쳐 어쩌고가 있지

그런데 "클린" , "코드스멜" 이런개념들 모두 상대적인거야

그래서 더 정확히 표현하려면 "~~보다 클린" 요렇게 해야해

이런 관계를 이해하지 않은 상태에서 저런 지식을 접하면 아래와 같은 일이 벌어져

더 좋은걸 보게되면, 갑자기 내 코드는 방금까진 "클린" 했는데, 갑자기 "더티" 코드가 되서 자괴감 느껴지게 되는거지.

그냥 이건, 방청소랑 똑같아

무균실을 만들꺼 아니라면, 적당한 수준에서 타협하고 가는거야

(근데, 영원히 무균실 못만들껄?)

그럼, 진짜 중요한 이야기를 해줄께

정말 중요한 것은 데이터 구조야!

여기서, 프로그래밍의 본질을 생각해보자.

프로그래밍은 결국 데이터 조작이야. [입력] -> [처리] -> [출력] 이잖아?

그래서 결과물에 지장을 주는 건 데이터 구조야.

데이터 구조가 변경되면 너가 아무리 대단한 클린한 구조로 설계를 했더라도 코드를 고칠 수 밖에 없어.

디자인패턴, 클린 아키텍쳐 어쩌고 저쩌고 지침 다 따랐으면 클래스 대량 생산되었을텐데 좀 아찔하다. 그거 다 고칠려면 어쩌냐..

아마도 구조를 변경한 기획자 욕하고 있을걸? 

그런데 게임이라는게 눈으로 돌아가는 프로토타입을 봐야 이게 재밌는지 아닌지 알 수 있거덩

전세계 어떤 게임도 데이터 구조를 한번에 확정한 경우는 없을꺼야.

그래서 역설적으로 최대한 데이터처리에만 집중해서 구조를 간단하게 가져가는게 좋아.

그럼 어떻게 해야할까?

일단은, 코드를 작성하기 전에 데이터 구조를 먼저 만들어야해.

이게 거창한건 아니고, 그냥 메모장 열고 JSON 작성하는게 끝임

예를 들어 아래 기능을 구현하려고 해.

- 몬스터 처치후 장비가 드랍됨

- 드랍된 장비는 랜덤으로 능력치가 결정됨

그럼 데이터 구조를 써내려 가보는거야. 

먼저, 드랍될 장비를 정의해볼께. 아마 쉬울꺼야.

장비 프로토타입: 

{

"key" : "sword-1",

"equip_type" : "sword",

"name" : "퇴마의 검",

"properties" : 

[

{

"key" : "attack",

"min" : 15,

"max" : 21

},

{

"key" : "atk_speed",

"min" : 0.7,

"max" : 1.2

}

]

}

장비 드랍 :

{

"id" : "xxxxxx",

"equip_type" : "sword",

"prototype_key" : "sword-1", //퇴마의 검 

"properties" : [

{

"key" : "attack",

"value" : 17

},

{

"key" : "atk_speed",

"value" : 1.1

}

]

}

( 만약 이게 안된다면 이것 먼저 연습하길 바람 )

데이터를 정의했다면, 이제 코딩하기 너무 쉬울꺼야

디자인패턴, 클린아키텍쳐등 머릿속에서 지워버리고

최대한 코드를 덜 만들 수 있는 방법으로 구현해봐

아마 할 수 있을꺼야.

참, 왜 코드를 덜 만들어야 하냐면 유지보수는 아래와 같은 과정이거덩

  1. 코드를 이해한다

  2. 코드를 변경한다

  3. 테스트 한다

그래서 유지보수가 쉬우려면 구조가 유연한게 아니라 코드량이 작아야 해

좋은 구조 만든다고 클래스 3~5개로 파편화 한 코드보다, 싱글턴이더라도 한 클래스에 있는게 더 좋아

(아래링크 꼭 읽어보자 ㅋㅋ)

개발자 1년차, 5년차, 10년차 코드 - 제타위키

참고로 나의 경우에는 아래처럼 만들것임

-----------------------------------------------------

파일명 : EquipItem.cs

public class EquipItemPrototype

{

public string Key;

public string EquipType;

public string Name;

public List<EquipItemPrototypeProperty> properties;

public static EquipItem CreateEquipItem(EquipItemPrototype prototype)

{

/* 아이템 생성 코드 */

}

public class EquipItemPrototypeProperty

{

public string Key

public float Min

public float Max

}

}

public class EquipItem

{

public string Id;

public string EquipType;

public string PrototypeKey;

public List<EquipItemProperty> 

public EquipItemPrototype EquipItemPrototype;

public class EquipItemProperty

{

public string Key;

public float Value;

}

}

----------------------------------

사실, 더 중요한 이야기는 기획자와 의사소통이야.

기획 = 데이터구조와 같아. 

그래서 기획자의 의도를 JSON 덩어리로 변경해보고, 이게 맞는지 기획자와 논의를 해봐

이걸 하지 않을 경우, 데이터 구조의 오해가 생겨서 코드 뒤엎는 경우가 꽤 있더라고..

기획의도대로 만들었지만 재미없어서 코드 갈아 엎는것은 의미있는 일인데, 

위 내용처럼 갈아 엎으면 너무 슬픈일이지. 꼭 피해야해!

------------------------------------

마지막으로, 그렇다고 내가 성공한 개발자는 아니니까 적당히 흘려들어

그럼 모두 화이팅하자!

[ㅇㅇ 1(203.253)]

팁: 링크는 웃자고 만든 오래된 밈이며 한 줄이면 끝날 코드를 베베 꼬아서 수십 줄에 걸쳐 만드는 사람들을 비꼬는 밈이기도하다. 5년차 주석을 보면 알 수 있듯 실제로는 엔터프라이즈에서 5년차식의 코드를 가장 많이 작성한다. 가장 많은 호응을 얻은 해석은 다음과 같다 "이를 말로 표현하면: 초보 프로그래머는 작은 프로그램을 작성합니다. 숙련된 프로그래머는 대규모 프로그램을 작성합니다. 전문 프로그래머는 큰 프로그램처럼 작동하는 작은 프로그램을 작성합니다."

[소닉쫄따구테일즈(dcz3xv7zgu14)]

그놈에 의존성 주입이랑 MVC패턴같은거에 빠져서 쓸데없는 세월 보낸거 생각하면...

[ㅇㅇ 3(61.109)]

Django 쓸 때 MVC 패턴은 존나 좋았는데 게임 개발에서는 다르게 쓰임?

[소닉쫄따구테일즈(dcz3xv7zgu14)]

MVC가 사실 웹에서는 분리해서 하기 좋은데, 게임UI들은 보통 기능(Model,Controller)가 바뀌면 View도 같이 바뀌는 경우가 허다하고, 재활용성도 한정적임. 그리고 V와C간에 인터랙션이 너무많은 인게임 UI같은 경우는 뭐 말할것도 없음. 그래서 MVC패턴으로 하다보면 MVC를 그냥 하나의 모듈에다가 다 작성하거나, VC가 한몸인경우가 많음... 그냥 단순한 UI만들떄마다 MVC셋다 만드는것도 개오바짓임

[ㅇㅇ 2(119.194)]

형님 유니티 유닛테스트는 어떻게 사용하면 좋은지 팁좀 주셔요 굽신굽신

[40살개발자(182.224)]

미안, 유닛테스트가 왜 필요한지 잘 모르겠음. ( 서버 프로그래머 따로 있다면, 서버 프로그래머는 유닛테스트 하는게 좋음 ) 1. 고친거 바로 눈으로 확인 가능하기 때문. 특히 핫리로드 같은거 쓰면 더 안써도 됨. 2. 클라이언트 유닛테스트는 배보다 배꼽이 더 커짐. 3. 보통 유닛테스트가 의미있는것은 회귀테스트를 통해 사이드이펙을 잡는건데, 이게 필요할만큼 프로젝트가 규모가 초 대형이 아니기 때문.

[40살개발자(182.224)]

그리고, 유닛테스트도 유지보수해야할 코드덩어리야. 나중에 뭐 고칠려고 할때, 이것까지 다 고쳐야 하나? 하고 현타온다.

[ㅇㅇ 2(119.194)]

아 이거 궁금해서 2년동안 끙끙댔는데 깔끔하게 정리해주셔서 감솨합니다 ^^)/~

[bowmore(qcs5jom3x9tq)]

[bowmore(qcs5jom3x9tq)]

좀 치네