전체 회고록
- 개발 및 기획 도중 생긴 이슈
- 인상 깊은 논의
- 프로젝트 초기(2022.12.27)와 비교(2023.8.5)(222일)
- 활동
기존엔 클래스 구조를 제대로 설계하지 못하였으나 개발 원활화를 위해 클래스 전반 구조를 뜯어고치면서 클래스에 대한 이해도 및 설계 능력이 향상되었다
같은 씬 충돌을 여러 번 겪으며 이에 대한 해결을 거듭하고 개발 기간 내 꾸준히 깃허브를 사용하여 깃허브 사용 실력이 향상되었다.
개발환경이 달라 예상치 못한 문제들도 다수 발생하고 이를 해결해 나아가며 배움
클래스별 구조화, 작업 분담, 함수 나누기 등을 진행하며 많이 배움
- To Do List간에 겹치는 개발 영역이 있어 개발자가 담당할 파트에 혼선이 있었음.
- 이슈 Close가 제대로 관리되지 않았음
- 파일 구조가 비효율적, 정리하는데 많은 노력이 들어감
개발 초반에 Pull Request를 하고 승인하는 방식으로 진행할지 각 개발자가 직접 Merge하는 방식으로 진행할지 논의 없이 각 개발지 직접 Merge 방식으로 진행하였다. 결과적으로는 다소 시행착오는 있었으나 크게 문제는 없었고 승인과정을 거치지 않았기에 빠르게 개발하는 데는 도움이 되었다. 하지만 개발을 시작하는데 앞서서 이에 대한 논의는 필요했다고 보인다.
개발 초반에 Naming Convention에 존재를 알지 못해서 이를 준수하지 않은 채 개발을 진행하다가 후에 네이밍 컨벤션을 준수하기 위한 리팩토링을 진행하였다. 이에 상당한 시간과 노력이 들어갔다. 개발 초반에 Naming Convention을 준수하며 개발을 시작하는 것이 좋을 것 같다.
- 회의 불참 여부와 같은 정보 전달을 팀장을 통해서만 진행하여 팀원간 정보 공유가 안되었던 점이 아쉬운 점으로 꼽힘
- 회의를 전문적인 용어를 사용하여 진행해 비전공자 기획자가 회의를 따라오기 어려웠던 문제가 있었음
생각보다 기획관련 문서들의 링크들이 정리 되지않아서 필요한 문서를 이용하는데 불편이 있었음. 예를 들면 모든 무기에 대한 정보를 작성한 무기 문서가 있는데 이에 대한 탐색 바가 따로 없어 일일이 드래그하며 찾아서 봐야했음, 이는 원래 탐색바가 존재했으나 나중에 탐색바를 수정하며 이 기능이 사라져서 발생한 문제임. 디스커션으로 논의해봤더라면 좋았을 것으로 보임.
같은 기능을 하는 클래스가 여러 개 있었다. 예시로 씬 이동 기능의 코드가 클래스간 중복되는 문제점이 있었다.
페어코딩의 시간대비 효율성이 높음을 몸소 느낌 각 개발자가 따로따로 개발하는 총 개발의 양질보다 페어코딩으로 개발하는 것이 생각보다 양질이 괜찮았음. 또한 이번 프로젝트에서 초중반엔 온라인으로 개발을 진행하다가 후반엔 포르아니으로 기획자까지 한 곳에 모여 개발하였다. 오프라인으로 개발자 기획자 한 곳에 모여 개발을 진행하니 개발 속도가 월등히 빨라짐을 체감하여 오프라인 개발의 필요성을 느꼈다.
개발자가 개발하며 코드를 작성하고 이 코드에 대한 참고용 문서를 작성해두었다. 이는 다른 개발자가 해당 코드를 이용 및 Develop 시키는 데 있어서 도움이 되었고 심지어는 해당 코드에 개발자도 나중에 해당 코드를 이용할 때 본인이 작성한 문서를 참고하는 것이 크게 도움이 되었다고 한다.
2023.8.05, 안병헌
