프로젝트 발표 피드백

여기 조 같은 경우, (피드백을 주신 튜터님께)단체로 오셔서 질문도 많이 하고 구조를 어떻게, 이렇게 짜는 것이 맞냐 이런 질문을 많이 하셨었다. 그때마다 정답을 알려드리진 않고 방향만 조금 알려드렸던 것으로 기억하는데, 그정도 키워드만 가지고도 팀원들끼리 잘 회의하시고 프로젝트를 이끌어 나가는 걸 보니 팀워크가 굉장히 잘 맞았던 것이 아닌가 하는 생각이 들었다.
결과적으로 좋은 결과물을 보여줘서 잘 봤다.

피그마를 활용하여 클래스, 클래스 이름, 메서드 등 미리 설계하고 진행했던 부분이 되게 좋다고 생각한다. 역할을 분담할 때 단순히 누구는 상점, 누구는 던전... 이런 것보다는 어떤 클래스를 만들어서 어떤 메서드들을 가질 거고, 이게 어떤 역할을 하는 건지 이런 약속을 미리 정해 놓고 진행을 하면 소통을 할 때도 도움이 되고 코드를 작성할 때도 막연하게 코딩을 했을 때보다 더 원활하게 작성할 수 있을 거라고 생각한다.
두 번째 트러블슈팅에서 말씀하셨던 것처럼 뭔가 이해할 수 없는 버그가 발생할 경우가 종종 있다. 로직은 완벽한 것 같은데 이게 왜 안 되지? 라는 경우가 많은데, 이런게 생각보다 눈에 잘 안 들어온다. 버그가 생겼을 때 코드만 바라보는 게 아니라 어디서부터 뭐가 잘못됐는지, 값이 잘못 들어갔는지 위치는 제대로 작성했는지 등을 확인해 보시면 되게 좋을 것 같다는 생각이 들었다.

- 느낀점

본격적으로 코드를 작성하기 전 구조를 잡는 작업에 시간이 좀 들었었는데 그만한 가치가 있는 시간이었다는 생각이 들었다.
이번에 피그마를 처음 사용해 봐서 작성하는데 어려움이 많았다. 다음에는 한 글자라도 더 적어봐야겠다... 틀리면 수정하면 된다!
발표 자료상으로 확인할 수 있는 사항들에 대해서 칭찬을 해주셨는데, 내가 발표 자료 제출을 할 때 전에 만들었던 레포지토리(작업은 두 번째로 만들었던 레포지토리에서 했음) 링크를 적어서 코드 관련하여 피드백을 받지 못했다. 절망적이었고, 제출하기 전 링크를 한 번이라도 검토했다면 일어나지 않았을 일인데 너무 후회되고 아쉬웠다. 😭 이번 일을 계기로 뭐든 제출하기 전에 확인하는 습관을 들이자...

다른 팀들의 발표를 보면서, 다음 프로젝트에서 우리 팀도 우리 팀만의 스토리와 아이템, 보스들을 만들어서 작업하면 더 재밌을 것 같다는 생각을 했다.