내일배움캠프 13일차 TIL + 팀프로젝트

팀프로젝트 진행

클래스 기능에 대한 합의

팀프로젝트 중에 팀원들간에 의견합의가 안되는 일이 있었다.
이런 부분은 충분히 고려했던 일이라 맨 처음 팀프로젝트가 진행되는 날인 월요일에 이를 미리 대비하려고 figma로 와이어프레임을 짜기로 했다
그 때 짠 와이어프레임에서 시간이 지나며 확장한 모습이 아래 모습이다.

위를 보면 모든 파일에 들어간 enum, 전역변수, 클래스 등을 다 표시하고 클래스나 메소드도 그 생성자가 받는 매개변수, return 값의 유형을 적고, 그게 어떤 역할을 하는지 써보기로 했다.
문제는 이런 일을 나도 처음해보고 아쉽게도 게임 기획 초기에 팀원 한분이 아프셔서 제대로 참여가 안되었다.
나중에 진행을 하다보니 결국 Monster 클래스에서 불필요하게 많은 메소드가 추가되었다.
대표적인 예시로 Dungeon에서 담당하게 할 생각이었던 배틀을 진행하는 메소드가 Monster class에서 만들어진채로 개발하신 팀원이 가져온 것이었다.
이에 대해 게임 구조의 중요성과 클래스들 기능 분할의 중요성, 그래서 왜 이 만드신 기능을 Dungeon으로 옮기셔야 하는지를 설명해드려야했다.

문제가 있다면 이게 잘못 말하면 쓴소리가 되고, 넌지시 슬쩍 말해서는 제대로 인지를 못하셨거나 자존감이 높으신 분이셨다.
그래서 팀원분과 팀원들을 도우려고 하는 것이라는 것을 확실하게 전달하기 위해 많은 고려를 한 끝에, 기획자가 꿈이시니 그것을 위해서는 게임 구조를 코드적인 면에서 이해하실 필요가 있으시다는 것을 얘기해드렸다.
그렇게 시작해서 왜 Monster클래스는 몬스터 자신에 관한 데이터만 저장하고 자신의 데이터 변화만 담당하는지, 왜 굳이 Dungeon이라는 클래스를 따로 둬서 거기서만 몬스터 생성, 전투, 클리어까지 던전에 들어가면 흔히 일어나는 일을 모두 처리하는지를 설명해드렸다.

다행히 이해를 하신 것 같다. 역시 초기에 와이어프레임을 짜기 잘한 것이, 그러지 않았다면 수많은 의견 충돌이 생겼을 것이다.
그리고 다음에는 좀 더 대담하게 팀원들에게 초반에 게임 구조의 중요성과 게임 구조를 짤때 기능 분배를 하는 방법에 대해 설명을 해드려야겠다.

팀원 제작 도움

팀원 중 한분이 변수 선언과 유저 클래스 타입 생성도 잘 못하셔서 많은 도움을 주게 되었다.
기초적인 부분부터 최대한 설명을 하며 진행을 하여서 Dungeon 클래스를 제작하였는데, 시간 안에 다 만들 수 있을지 살짝 걱정이 되어서 어떻게 구현할지 명확하게 설계를 해둬야할 것 같다.