[🐣질문] 너네는 코드 리뷰 누구한테 부탁하냐. 나 초보개발자라 도움이 필요하다.

[ㅆㅇㅆ(124.216)]

이렇게 싱글톤으로 잘 되던거

이렇게 동일하게 짰는데, 일단 아이템 이미지를 받아오질 못하는건 일단 내가 코드 구조때문에 일부러 뺀거

근데 이거는 문제 원인 파악 못한게 아니라. 사실 어디에 이미지 받느냐 코드 수정 문제라 .이거는 뭐 수정하면 되는 부분이라 별거 아님

어쨌건

거의 다 완성됐음. 리팩토링만 계속했는데 초보 개발자인 내 수준에 맞게 코드 짰지만 잘 짰는지를 모르겠다.

후에 문제가 있을지 없을지도 모르겠고

근데 게임 개발 연차가 1년이 안되니까

내 코드가 맞는지 안맞는지 도저히 가늠이 안된다.

이럴때는 너네는 코드 리뷰 하거나 하냐. 어떻게 하냐

대략 내 코드 구조는 이럼

1.게터 세터는 메서드로 가져와서 가져오게함. 모든 필드는 private이고 외부에서 가져와야할 필드만 게터 세터 메서드 씀

2. 직접 참조 안하고, 다른 매니저에서 참조해야할 게터와 세터를 인터페이스로 해서 가져옴

3.인벤토리 시스템 팩토리에서 매니저들 초기화와 더불어서 의존성을 주입함.

여기에서 필드 아이템, 인벤토리 아이템 생성시 의존성 주입도 담당함

인벤토리 플로우는 다음과 같음

0. 인벤토리 시스템 팩토리에서 의존성 주입

1. 슬롯 그리드에서 슬롯 생성

2. 슬롯 그리드 매니저에서 슬롯 그리드에서 정해둔 수량만큼 받음

3. 인벤토리에 저장되는 아이템 매니저-슬롯 매니저-컬러 매니저가 있음.

아이템 매니저: 인벤토리에 저장된 아이템 데이터 사용 및 아이템의 x값 y값을 리스트로 저장해둠

슬롯 매니저:아이템이 점유 됐을때, 슬롯 색깔 변경 및, x,y값 리스트를 슬롯에 맞게 체크함

컬러 매니저-아이템이 점유됐을때 아이템 점유수에 따라 슬롯 색상 변경

4.저장된 아이템 체크->리스트에 저장된 아이템의 위치를 슬롯 매니저에서 체크->슬롯 위치 체크 되면 컬러매니저에서 그리드 컬러 변경-> 인벤토리 그리드 매니저에서 최종적으로 전체 데이터 다시 값 체크

이런식의 구조를 하고 있는데

내가 코드를 잘 짜고 있는거 맞냐.

GPT한테 물으려고 하니까 GPT는 내 코드 전부 저장을 못해서 답변을 제대로 못해줌.

코드를 너무 나누니까 얘가 없는 기능을 자꾸 추가 시킬려고 함.

이렇게 분리 시켜서 관리해야하는거 맞는지도 모르겠고.

그냥 시리얼 라이즈 필드로 인스펙터 상에서 추가할 것을 괜히 귀찮게 짜고 있는지도 모르겠고

지금 대부분 코드를 이렇게 해서 짜다보니 생산성이 많이 낮은 편인데, 이렇게 짜는 방식이 맞는지도 모르겠다.

현업인 애들은 어째 짜냐

이렇게 구조를 짰을때 뭔가 문제가 될만한게 있을까? 싱글톤을 안쓰고 팩토리 패턴을 이용해서 이렇게 구현을 했는데

이게 맞는 방법인지를 전혀 모르겠음..

의존성 주입<<이거 갤에서 키워드만 얻고 내 나름대로 진짜 생각하면서 만들어봤는데 이게 진짜 맞는 방법인지 몰겠다

내 프로그래밍 버릇들이 협업에 문제가 될 만한게 있냐?

일단 최대한 패턴 코딩 익히면서 구현하고 있는데, 진짜 맞게 하고 있는건지 내 자신이 긴가 민가하다.

아무래도 선배가 없어서 독학 때리고 있어서 그런가

[ㅇㅇ 1(14.36)]

게터 세터 함수는 자바에서나 쓰고 c#이면 프로퍼티ㄱㄱ

[ㅆㅇㅆ(124.216)]

프로퍼티로 전환? 오케이 다음 또 해야할꺼는? 나 캡슐화를 C++ 배울때 이렇게 배워놔서..

[익명(121.169)]

Player 클래스에서 물약을 먹는 기능이 있을 때 어떻게 호출하면됨?

[익명(121.169)]

내부 구현이 뭐든 님 코드 몰라도 쓰기 쉬우면 장땡이지

[ㅆㅇㅆ(124.216)]

아이템 매니저의 리스트에서 삭제하고, 컨슘 분류 아이템의 효과 발휘하게함 포션은 컨슘분류 인터베이스

[ㅇㅇ 2(119.196)]

7번째 사진 같은 null 체크는 Aseert.IsNotNull 쓰면 좋을듯

[ㅇㅇ 2(119.196)]

저 게임오브젝트 구성이 동일할 거라면 AddComponent 대신 RequiredComponent 어트리뷰트 써도 될거 같은데?

[ㅆㅇㅆ(124.216)]

수정함 고맙다

[ㅇㅇ 3(183.100)]

난 고수는 아니지만.. 내가 생각하는건 두가지 정도인데 1. 문제없이 짜면 잘짠거다. 2. 지금 만든 함수만 따로 떼다가 다른데 붙일수있냐. 이정도 -> 저런 인벤토리를 저기서만 쓰는게 아니라 비슷하게 게임 내에서 쓸 경우가 생길꺼임. 아니면 차기 프로젝트에서 쓰던가. 그럴때 저 함수나 클래스만 떼가면, 다른 부가적인것들 안 만들어줘도 사용가능하냐는 거임. 함수같은 경우는 파라미터만 받으면 됨 -> 이걸 확인하면 의존성체크가 간단해짐.

[ㅇㅇ 4(14.63)]

나도 이생각

[익명(119.70)]

인터페이스는 비슷한 애들이지만 내부기능이 틀려질때 많이 넣음. 저걸 인벤토리 슬롯에만 쓸거면 오히려 코스트 낭비임 인터페이스가 가장 느려서

[흉황(smk4397)]

클래스마다 전용 인터페이스를 쓸거면 도대체 인터페이스를 쓰는 이유가 뭐임 - dc App

[ㅆㅇㅆ(124.216)]

근가

[ㅆㅇㅆ(124.216)]

고수준 모듈이 저수준 모듈에 의존하지 않기때문에 DIP를 지킬 수 있다는 장점이 있다고 해서 쓰고 있는데 흠

[흉황(smk4397)]

dip에 대해 좀 오해하고계신 것 같은데 인터페이스로 저렇게 레이어 하나 추가한다고 해서 의존성이 사라지는 게 아님 사진처럼 ISlotManager는 SlotManager 클래스"에만" 쓰이는 인터페이스일거 야녀? 이건 그냥 추상화에만 그치는 거고 "슬롯 매니저"라는 저수준모듈에 의존성이 있는 건 마찬가지라는 얘기임 - dc App

[ㅆㅇㅆ(124.216)]

그러고보니 그러네

[익명(121.139)]

지피티한테 코드 리뷰를 왜 받지..

[GodotOgre(d4f27pjh3cac)]

니가 잘짠 코드인지 아닌지 가장 쉬운 방법은 니가 짠 코드를 니가 짜지 않았다 생각하고... 외부인이 니 코드를 가져다 쓴다고 생각하면 쉽다... 인벤 클래스를 만들었으면 캐릭터 클래스 만드는 사람이 니 인벤 클래스를 가져다 쓴다고 생각하고 인벤 인터페이스에 접근해서 쓴다고 해봐... 내부 구현은 어떻게 하든 상관없다... 캐릭터 클래스 만드는 사람이 인벤에 쉽게 아이템을 넣고 뺄수 있는지... 그것만 잘되면 문제 없는 코드임

[GodotOgre(d4f27pjh3cac)]

그리고 인터페이스에 잘못된 사용이나 인자등을 넣었을때는 철저하게 ASSERT가 걸리게 하여 인벤을 잘못 사용하면 바로 알수 있게 만들면 좋음

[ㅆㅇㅆ(124.216)]

좋은 방법 알아간다 고마워