[팀 프로젝트][KPT 회고] 4. 타워 디펜스 웹게임 제작

시작 화면

게임 플레이 화면

개요

이번에는 3명의 팀원들과 함께 간단한 타워 디펜스 웹게임을 제작하였다.  언제나 그랬듯 6/17~6/21까지 총 5일동안 협력하면서 무엇이 좋았고, 어떤 문제가 발생했었는지, 그리고 문제를 어떤 식으로 해결했는지 또는 어떤 식으로 해결하면 좋았을 지 KPT 방식으로 회고해보자.

 

참고

• 이번에는 내가 팀장이 아니었기에 KPT회고록 내용은 팀장분이 적어서 각 팀원의 KPT 내용이 구분되어 있지 않았다.
• 내 의견을 넣는다는게 까먹어 버리는 바람에 내가 넣은 의견이 없어서 내 의견을 따로 적어놓았다.

팀에서의 내 역할: 팀원

 

https://github.com/tmdwnsasa/Tower_defense

GitHub - tmdwnsasa/Tower_defense

 

---

 

Keep - 현재 만족하고 있는 부분

Github Projects 기능을 사용하여 각 팀원이 서로 무엇을 개발해야 하는지, 개발하고 있는지 알고 분업을 확실히 할 수 있었다.
각자의 역할 분담이 확실하여 적은 인원으로도 프로젝트 개발이 차질이 없었다.
각자 프로젝트에 참여하는 의지가 보여 좋았다.
서로간의 의견을 존중하며 의론하여 좋은 코드를 짜기 위해 노력했다.

 

깃헙 이슈, 프로젝트 기능 사용 ( 내 의견 )

• 이번 팀 프로젝트에서 특히 좋았던 점은 깃헙에서 이슈와 프로젝트 기능을 사용했다는 점이다. 존재만 알고있었지 어떻게 사용하는 지 몰라 나중에 사용하는 법을 배워야겠다는 마음만 있고 알아보는 것을 계속 미뤄왔는데 이번에 팀장분이 사용하자는 의견과 함께 사용하는 법을 알려줘, 보다 적극적으로 깃헙 기능(이슈, 프로젝트)를 사용할 수 있었다. 프로젝트의 규모가 커지고 팀원이 많아질수록 다른 사람이 어떤 일들을 해왔는지 알기가 어려워지는데 이렇게 이슈, 프로젝트를 사용하니 보다 일의 흐름과 팀원의 작업 내용을 보다 쉽게 알 수 있었다.

이슈 작성 및 관리

프로젝트 사진

 

code convention 정하고 시작 ( 내 의견 )

• 저번 프로젝트에서 가장 힘들었던 점이 code convention이 없는 채로 시작해서 변수 이름들이 통일되어 있지 않았다는 점이다. 매번 변수 이름을 틀려서 오류가 발생했던 것이 기억에 남는데, 이번에는 확실하게 모든 코드 작성 방법들(camelCase, pascalCase, 함수 이름은 동사로 시작 등등...)을 정하고 가니 나중에 다른 사람들의 코드를 볼 때 너무나도 편하고 좋았다. 이렇게 code convention을 꼼꼼하게 정하고 가니 삽질하는 경우도 훨씬 줄어들고 다른 사람의 코드의 로직을 이해하는데도 한결 편했던 것 같다. 앞으로도 code convention을 미리 작성하고 가도록 해야겠다. 

Problem - 불편하게 느끼는 부분

서로의 코드를 잘 알고있던것도 한몫하겠지만 코드리뷰 시간이 비교적 적었다.
도전과제가 끝나고 리펙터링이나 검증에 대해 추가하느라 추가구현을 하지 못했다.
깃 머지 이후 가끔 사소한 버그가 났었다.

 

정해진 방향성의 부재( 내 의견 )

• 팀 프로젝트를 할 때 가장 중요한 것 중 하나는, 프로젝트의 목표를 설정하고 팀원들에게 프로젝트의 방향성과 프로젝트에서 본인의 역할이 무엇인지 정확히 인지시키는 것이라 생각한다. 이것이 정확하게 이루어지지 않으면 팀원들이 본인의 무엇을 해야하는지 헤매거나 삽질을 하는 경우가 여럿 발생하게 된다. 이런 경우들이 하나하나 쌓이게되면 프로젝트 진행 속도를 늦추는 결과를 초래하는데, 이번 프로젝트의 모든 팀원이 역량이 충분했음에도 불구하고 결과물이 아쉬웠던 이유가 이런 이유에서이지 않을까 싶다. 프로젝트 개발 중반까지야 만들어야할 내용이 어느정도 정해져 있어 방향성이 정해지지 않았어도 큰 문제가 없었지만, 후반에 갈수록 방향성을 잃어 아이디어만 받고 결국 아무것도 추가 개발하지 못한 채 흐지부지 끝나버렸다. 다음부터는 시작할 때 최소한의 방향성이라도 설정해야겠다.

왜 계획이 없었을까 (내 의견)

• 이번 프로젝트에서 대부분의 불만은 마무리 작업에서 나타났다. 앞으로의 할 일들이 있을 때 이런 일들을 계획없이 되는대로 처리하다보니 프로젝트의 완성 정도를 알 방법이 없었다. 그나마 이슈와 프로젝트에 기록이 남아있어 기능 구현에 대한 진도는 쉽게 알 수 있었지만 전반적인 워크 플로우는 알 수가 없었다. 데드라인도 없고, 앞으로의 계획도 딱히 없으니 개발하기에는 여유로워 편했지만 활용할 수 있는 시간들이 많이 낭비되지 않았나 싶다. 이런 시간들을 잘 활용해서 마지막에 리팩토링이나 클린 코드 작업을 진행했더라면 보다 좋은 프로젝트 결과물이 나오지 않았을까하는 아쉬움이 있다.

Try - Problem에 대한 해결책, 당장 실행 가능한 것

코드리뷰를 함으로서 서로의 코드를 모르는 일이 없도록 하고 어떤 의도로 해당 코드를 짰는지에 대하 알 수 있도록 해야겠다.
시작하기 전에 각자의 역량을 생각하여 추가구현 기획을 미리 해두는 것이 나을 것 같다.
풀리퀘스트를 받기 전에 해당 코드에 버그가 없는지 좀 더 꼼꼼히 확인해야겠다.

 

코드 리뷰 (내 의견)

• 결국 팀원들이 짠 코드를 정확히 이해하지 못한 채로 코드를 짜면, 코드들의 일관성이 조금이라도 더 흐트러지는 것 같다. 팀원들이 병렬적으로 작업을 진행하는 만큼 해당 기능을 맡은 팀원이 그렇지 않은 팀원들보다 해당 기능에 대한 이해도가 높고 로직에 대한 설명또한 더 잘할 것이다. 그렇기에 간단하게라도 기능에 대한 설명과 로직 구현 아이디어를 공유하는 코드 리뷰 시간을 자주 가지는 것이 필요해보인다. 다음 프로젝트에서는 한 사람당 5분정도 본인 코드를 설명하는 시간을 가지는 것이 좋아보인다.

---

마지막으로...

여러 이유로 인해 이번 팀 프로젝트에서 팀장이 아닌, 팀원으로 들어간 것은 다양한 관점과 생각을 할 수 있었던 기회가 되었다고 생각한다. 리더와 팔로워를 번갈아가며 하면서 내가 어느 역할에서 더 좋은 역량을 보일 수 있는 지 알 수 있었고, 어떤 식으로 리딩을 해야 팔로워가 편한 지, 반대로 어떤 식을 리딩하면 팔로워들에게 오해가 발생하는 지 알 수 있었다. 처음으로 제작해본 게임 서버 프로젝트인 만큼 많은 아쉬움이 남지만 내가 할 수 있는 최선을 다했기 때문에 후회는 없는 프로젝트이다. 지금 많이 부족하다는 것이 느껴지지만, 부족하면 부족한대로 더욱 더 열심히 해보려고 한다.