[🐣질문] 만들던 프로젝트의 참조랑 상속 관계를 그려봤는데용

[로케트는어떻게..(injjj4444)]

스크립트가 어떤 스크립트를 참조하는지, 상속하는지 표현한겁니다. 어떤 함수가 어떤걸 참조하는지까지 들어가면 다 못할 것 같아서..

뭔가 더럽게 꼬인 느낌인데요. 문제 많은거죠 이거?

중간에 관리자와 일반 스크립트를 잇는 또다른 관리자를 둬야할까요 아니면 인터페이스? 이거 좀 깔끔하게 바꾸고 싶은데 말이죠.

만들 때는 체계적이라고 생각했는데 이렇게 보니까 그냥 코미쥬르네요..

[익명(1.235)]

심각

[로케트는어떻게날아?(injjj4444)]

그쵸..? ㅠㅠ..

[고닷(m4odn36nekku)]

오... 이뻐요

[고닷(m4odn36nekku)]

일단 관리자두고 정리하는게 나을듯한데 1인개발이면 그냥 완성부터 ㄱ

[고닷(m4odn36nekku)]

교훈삼아 차기작부터 정리를...

[로케트는어떻게날아?(injjj4444)]

게임은 완성되어 있습니다. 이리 검색하고 저리 검색해봐도 정리하는 감이 안잡혀서 문제네요.

[로케트는어떻게날아?(injjj4444)]

완성해놓고 어떨까 싶어 연결해보니 저지경이네요.

[고닷(m4odn36nekku)]

오 코딩할때 별 문제 없었고 유지보수 문제없다면 차기작 ㄱㄱ

[고닷(m4odn36nekku)]

리랙토링지옥은 힘들어 ㅠ

[로케트는어떻게날아?(injjj4444)]

일단 다음 개발로 넘어가긴 해야겠네요. 대신 좀 더 깔끔하게..

[차별없는차단(pnacrd8pn5la)]

대충 훑어봤는데 가장 큰 문제는 어떠한 기능을 만들때, 그 기능에 필요한 재료들을 여기저기서 마구 끌어다 쓴게 눈에 띔. 하나의 기능을 구현하는데 이게 필요하다 싶으면 바로 그 데이터가 있는 클래스를 참조하거나 매니저를 만들어서 쓰거나 한거 같은데 맞음?

[차별없는차단(pnacrd8pn5la)]

만일 그런 식으로 구현했다면 자연스럽게 저런 스파게티 구조가 됨. 어떠한 데이터를 누가 어느 타이밍에 어떻게 공개할지 조금 더 고민한다면 훨씬 깔끔하게 짤 수 있으거라 생각

[로케트는어떻게날아?(injjj4444)]

어떠한 데이터를 누가 어느 타이밍에 어떻게 공개할지가 무슨 의미인지 잘 모르겠습니다만.. 찾아보겠습니다!

[차별없는차단(pnacrd8pn5la)]

예를 들어서 사운드매니저를 보자. 사운드 매니저가 여기저기서 사용되고 있는게 이게 그럴 필요가 있냐? 라는거지. Weapon쪽에 사운드 매니저가 붙어있는데, 무기를 사용할 때 효과음을 내고싶다! 라는거라고 생각함. 그러면 Weapon 쪽에서 사운드 매니저를 직접 불러도 되지만, 그것보다는 Weapon이 사용되었다 라는 이벤트를 발생시키고 사운드 매니저는 그 이벤트를 받아서 적절한 효과음을 플레이 시키면 되지 않을까? 이렇게 만들면 Weapon하고 사운드 매니저는 서로 참조 안해도 되게 됨

[로케트는어떻게날아?(injjj4444)]

오, 말씀하시고자 하는 건 알겠네요. 근데 결국 이벤트를 발생시키고 받는 과정에서 무언가 연결이 필요할텐데 그 연결은 인터페이스로 해주면 좋을까요?

[차별없는차단(pnacrd8pn5la)]

나는 스크립터블 오브젝트 이벤트 시스템을 많이 사용함.
스크립터블 오브젝트를 사용하지 못할때는 따로 이벤트 채널용 클래스를 하나 만들어줌.
https://youtu.be/WLDgtRNK2VE

[차별없는차단(pnacrd8pn5la)]

이벤트 시스템을 사용하던 다른 시스템을 사용하던 결국 중요한건 각각의 기능을 독립시키고 서로 참조하는것을 최대한 줄여야 나중에 기능 추가 변경 하기 쉽고 테스트 하기도 쉬워짐. 너 지금 상황에서 테스트는 거의 못하고 있지 않음? 하나 기능 테스트 할라면 여러가지 매니저 준비시키고 매우 골아플거 같은데

[로케트는어떻게날아?(injjj4444)]

감사합니다. 말씀해주신 것 많이 참고해보겠습니다! 근데 테스트는 아예 할 줄을 몰라서요.

[차별없는차단(pnacrd8pn5la)]

여튼 여러 매니저가 서로 다른 매니저를 서로서로 참조하는 지금 상황은 별로 바람직해 보이지 않고, 게임의 규모가 커지면 코드 추가 변경에 시간이 많이 소모될듯. 수도꼭지 변경했더니 화장실 터지고, 화장실 고치니까 가스렌지 불나는 상황이 올거라는거 그러니까 데이터는 되도록이면 공개하지 않도록하고, 꼭 그 데이터가 필요할때는 상시공개가 아니라 이벤트 시스템같이 필요한 타이밍에만 공개하는것만 고려해보고, 꼭 상시공개가 필요할 때에는 readonly 등으로 설정해서 데이터 변경에 제한을 거는것을 추천.

[로케트는어떻게날아?(injjj4444)]

감사합니다! 조금 빛이 보이는 것 같아요. 이 다음 개발에는 더 깔끔하게 만들어보겠습니다!

[차별없는차단(pnacrd8pn5la)]

근데 지금 내가 말하는건 나 혼자 일하면서 독학한거라서 일반적인 이야기가 아닐수도 있음. 걍 이렇게 생각하는 코드몽키도 있구나~ 정도로 생각해주면 좋겠음

[로케트는어떻게날아?(injjj4444)]

넵

[중력의질서(jhm3595)]

학1원에서 이렇게배웟엇는데 나도 글쓴이처럼하고 있었네 도움되었읍니다.. - dc App

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

심각할필욘없는게 Sound나 ResourceManager같은 초상단 유틸리티시스템은 참조가 많은게당연한거임. 그렇게따지면 유니티의 스크립트들이 MonoBehaviour상속많이하는것도 문제라고 봄? 그건 아님.

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

특히 저 싱글턴 쟤는 사실 UML에 포함시키지도 않음. 그냥 클래스명옆에 Singleton적는걸로 표현함. UML은 가시화가 쉽도록 하기위해 쓰는거지, 일일이 다 있는그대로 표시하면 보기 힘들어

[로케트는어떻게날아?(injjj4444)]

흠.. 그걸 차치하더라도 문제가 있긴 하겠죠? 싱글톤을 지워도 여전히 거미줄이라..

[고닷(m4odn36nekku)]

난 거미줄이 많은거보단 만든사람이 유지보수하기 편하다면 괜찮다고봄

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

저 클래스들의 기능을 하나의 클래스 Game이라는거에 다 때려넣으면 화살표 없어짐. 근데 그게 바람직한게 아니잖아. 그 클래스안에서는 보이지 않는 화살표들이 득실거리는데 UML상으로 안보일뿐이지. 요구사항이 다양하고 까다로운 프로그램은, 대체로 관계도 복잡한 편임. 막 F=ma같은 공식처럼 깔끔하게 안떨어져. 참조에 대해 너무 의식하진마삼.

[로케트는어떻게날아?(injjj4444)]

알겠습니다. 너무 의식하진 않을게요. 좀 깔끔하게 다듬는 정도로 만족하겠습니다!

[익명(14.52)]

이런거 별로 신경 안써도 됨..

[익명(211.214)]

인디면 뭐 구현이 우선이지 만약 깔끔한 코드를 원하면 매니져끼리 디커플링좀 하고 차라리 델리게이트로 쏴서 필요함 놈만 받는게 나을듯 지저분하긴함