🧙♂️ God Object전지전능한 오버시어, 고장나면 세계종말(?) '갓 오브젝트'는 특정 오브젝트/스크립트가 한 씬(플로우, 시퀀스 등)에서 너무 많은 역할/책임을 가지게 되는 것으로 관리 혹은 오류에 취약해질 수 있는 상태가 될 수 있다. 유니티 게임 개발을 예로들면, 'GameManger' 클래스를 만들고 모든 흐름 제어를 'GameManager'가 하는 것과 같다. 이는 관리 차원에서는 쉬울 수 있다. 게임매니저가 허브의 역할을 하여 디버깅이 단순하고 각 매니저, 컨트롤러들의 독립성도 지킬 수 있다. 단, 이러한 경우 "기능 추가 = 게임매니저 코드 증가"로 쌓이게 되고 분기 처리와 책임 분리가 모호해질 수 있다. 또한 간단한 작업도 게임매니저를 통과해야하는 불필요한 절차가 반강제적으로 이..
프로파일러 확인1. Draw Calls 확인Rendering > Batches 항목 확인 항목설명SetPass Calls서로 다른 머티리얼이 사용된 횟수 (높을수록 병목) Batches실제로 GPU로 보낸 드로우콜 수 (100~200 이상이면 병목 가능성 있음) Triangles, Vertices너무 많은 버텍스나 면이 합산되는지 확인 2. UI 관련 병목 확인UI가 주 원인이라면 Canvas.RenderOverlays, Canvas.SendWillRenderCanvases 등이 비정상적으로 높은 시간을 차지Hierarchy 탭에서 Canvas 하위 구조 복잡도 확인 3. Frame Debugger 병행 사용Window > Analysis > Frame Debugger플레이 중에 Enable을 누르면 한..

이번에 개발하다가 사운드 클립 리소스를 필요할 때 메모리에 올리고 사용이 끝나면 모든 레퍼런스를 제거하는 로직의 스크립트를 작성했다. (유지보수를 위한 커스텀 GUI는 덤) 하지만 해당 리소스의 모든 레퍼런스를 제거했어도 실제로 메모리에서 해당 사운드 클립 리소스가 내려오지는 않았다. 아마 메모리가 부족해진다면 가장 먼저 가비지컬렉터에 의해 정리되긴 하겠지만 이렇게 레퍼런스가 없더라도 정리되지 않는 이유라면 굳이 매번 레퍼런스가 0인 데이터를 제거하는 것도 시간이 걸리는 작업이고 아마 캐싱 같은 개념으로 사용할 수 있을 것 같다. 리소스의 메모리 사용 과정A라는 사운드 클립을 사용하려 한다.저장소에서 메모리로 A 사운드 클립 데이터가 올라온다.올라온 데이터를 신나게 쓴다.다쓰고 해당 데이터와 연관된 모든..
SOLID Principle SOLID 원칙이란, 객체지향 프로그래밍에서 소프트웨어 디자인을 위한 5가지 지켜야 하는 원칙이다. 이 원칙을 통해 소프트웨어의 유연성, 확장성, 유지보수성을 향상한다. 1. 단일 책임 원칙 (Single Responsibility Principle : SRP) 하나의 클래스는 하나의 책임만 가진다. 단일 책임 원칙은 하나의 클래스는 하나의 기능만을 책임지는 것이다. 클래스 하나가 다수의 기능을 구현하는 것은 단일 책임 원칙에 위배된다. 이는 캐릭터에 움직임, 사운드, 애니메이션 등을 하나의 클래스가 모두 통재하는 현상이다. 그렇다면 단일 책임 원칙을 준수하면 어떤 이점이 있을까? 단일 책임 원칙의 이점 이점 설명 가독성 증가 단일 기능 단위로 분리된 코드는 가독성이 늘어난다..