[💬] 아래 바보 같은 ~ 이라고 적은 글..

[도적코볼트(w9716www)]

혼자 개발을 한다면 사실 아무렇게 해도 상관없음. 본인이 고생하니까. 그런데 문제는 본인이 고생한다는 점에 있음.

위의 그림을 보면 비슷한 부분이 굉장히 반복되고 있음. 가급적 반복되는 부분은 줄여나가는게 훨씬 가독성에 도움이 됨.

누구는 이렇게 생각할 수도 있음.

" 한 줄 한 줄이 딱딱 떨어져서 더 가독성이 좋지 않냐? "

그런데 이런 말은 무슨 소리랑 같냐면

숫자가 1~10 까지 있을 때, 일 이 삼 사 오.. 십 이렇게 말하는거랑

10이하의 양의 정수.

이렇게 말하는 거에 대해서 차이가 있다는 점임.

대충 짠건데 이런 식으로 짠다면 더 짧게 쓸 수 있다는 점임.

위에서 가장 문제점은 transform.Find( 스트링 값 )

바로 여기 스트링값이 바뀔 경우에 직접 스크립트로 들어가서 일일이 다 바꿔야한다는 점임.

만약에 이게 위의 사진처럼 몇 개가 안되면 상관이 없지만 게임이라는게 굉장히 복잡한 시스템으로 구성되어 있는데

이 경우에 무엇인가 바꾸려고 하면 일일이 찾아다녀야 하거나 엄청나게 귀찮아질 수 있음.

( 추가로 적으면 원하는 상황에 따라서 enum값에서 스트링 빼던지, 아니면 transform.Find에들어가는 스트링만 따로 선언해서 쓸 수 도 있음. 단순히 예씨를 위해서 대충 쓴 코드임 )

그런데 왜 저런 식으로 했을까 여러 이유가 있겠찌만 추측을 해보자면 이 부분일 수도 있다고 생각함.

이베이젼과 블록이라는 값이 있을 때 ( 정수값을 )

하나하나 변수를 선언하는 것과 ( 맨 위에 어떤 갤러가 올린 것처럼 )

어레이나 리스트 형태로 관리하는 것 ( 내가 쓴 방식 )

이 두 개의 차이점은 어디에 있을 수 있는가?

바로 인스펙터에서 확인이 가능함.

변수를 따로 선언하게 되면 선언된 변수의 이름으로 인스펙터에서 볼 수 있어서 쉽게 알아 볼 수 있음.

그러나 리스트나 딕셔너리 형태로 저장하게 되면 각각의 이름이 인스펙터에서 확인이 불가능함.

( 물론 코드에서 접근할 때는 valueAry[ (int)testType ]의 형태로 접근하면 코드 상에서 보기는 불편하지 않을 수 있음 )

이 부분 때문에 따로 에디터를 만들거나 ( UnityEditor를 이용하면 쉽게 만들 수 있긴한데.. 게임 엔진 안에서 또 그런 행동을 하는 것은 어쩌면 일을 위해서 더 일을 해야하기 때문에... 잘 생각해야겠지 ) 이런 부분들이 안좋을 수 있음.

그래서 여러 개발상황이나 자기가 원하는 상황에 맞춰서 선택해야한다고 생각함.

- 정리 -

변수를 하나씩 해놓는 것은 케이스 바이 케이스지만 나중에 불편해질 가능성이 매우 높지만 유니티 엔진에서 인스펙터에서 확인할 떄는 좀 더 쉽게 가능함.

변수를 하나씩 선언하는 것이 아니라 여러 컨테이너 형식으로 가지고 있다고 가정한다면 관리를 쉬울 수 있으나 유니티 엔진에서는 인스펙터에서 확인시 불편할 가능성이 높음. 그래서 이것을 해결하기 위해서는 유니티에서 에디터를 직접 만들 수 있지만 이것도 일이라 더 일을 할 수도 있음.

조금 쓸 때 없긴한데 오늘 쉬면서 어제 봤던 글에 대해서 적어봤음..

[박재민(devomegathree)]

조언추;;