[C#/TIL] TextRPG 팀 프로젝트 마무리

📝 팀 프로젝트를 마무리하며

팀 프로젝트를 하면서 배워가는 것들이 정말 많았는데, 오늘은 다음 팀 프로젝트 때 참고할 수 있는 플젝 진행 방식과 관련된 좋았던 점과 아쉬웠던 점을 정리해보겠다. 

우리팀 단체사진

 

우리팀 깃허브 https://github.com/yndoo/Dun9eonAndFi9ht

GitHub - yndoo/Dun9eonAndFi9ht

---

좋았던 점 1. 자세한 개발 계획(특히 클래스 설계)

지난 프로젝트때마다 개발 계획 단계가 너무 중요하다고 느껴서 이번에 팀장을 맡게된 김에 팀원분들께 계획을 상세하게 짜고 시작하고 싶다고 말씀드렸다. 모두가 동의해주셔서 하루는 온전히 계획하고 회의하는 데에 쓰였다. (나중에 말씀하시기로는 다들 이전 프로젝트에서 느꼈던 바가 비슷하셨다고 하심.) 설계가 탄탄하니 계획된 부분까지의 개발이 정말 빠르게 끝났다. 필수 기능부터 만들고 도전기능에 천천히 들어가자고 했었는데, 필수기능은 하루안에 끝나버렸다! 게다가 팀원 전원이 프로젝트 진행을 잘 파악하고 있어 소통이 너무 수월했다.

 

첫 작업 들어가기 전에 깃허브에 계획한 대로 틀(Class 생성, public 프로퍼티 생성, 파일 분리 등)을 만들어 올려드렸는데, 이것부터가 만들기 좋게 되어있어서 매우 도움되셨다는 피드백이 있었다. 😆

 

한 줄 요약
계획을 제대로 짜고 시작하니 개발이 빠르고 팀원간 소통이 원활

 

이건 구현된 기능 리스트 자랑 : 필수 기능은 물론이고 도전 기능에서 1개 빼고 다 만들었당

기능	설명
🏠 마을	처음 시작하거나 플레이어가 죽으면 새 캐릭터를 생성합니다. - 이름과 직업을 입력받습니다. - 메뉴 선택으로 다른 기능으로 이동할 수 있습니다.
📜 상태 보기	현재 캐릭터의 정보(레벨, 장비, 능력치 등)를 표시합니다.
⚔ 전투 시작	특정 층의 던전에서 전투를 시작할 수 있습니다. - 층이 높아질수록 몬스터 레벨 증가 📈 - 몬스터마다 보상이 다름 💰 - 플레이어 턴에는 공격, 스킬, 포션 사용, 도망치기 중 선택 가능
⬆ 층 이동하기	클리어 기록이 있는 던전으로 다시 이동하여 플레이 가능합니다.
🎒 인벤토리	던전 클리어, 퀘스트 성공 시 획득한 아이템과 포션을 확인합니다. - 아이템은 장착 부위마다 하나씩 장착 가능 🛡 - 아이템 개수가 많아지면 페이지 넘김 지원 📖
📜 퀘스트 수주	- 아직 받지 않은 퀘스트를 확인하고 수락/거절 가능 ✍ - 진행 중인 퀘스트 & 완료한 퀘스트 목록을 확인 가능 ✅
❌ 게임 종료	마을에서 게임을 종료할 수 있습니다.

---

좋았던 점 2. 협업 규칙 정하고 지키기 (코드 컨벤션, 깃 컨벤션)

코드 컨벤션과 깃 컨벤션을 배운대로 전부 적용해보고자 했다. 깃 컨벤션은 처음으로 지켜봤는데, 실제로 버그 원인 추적에 큰 도움이 되는 경험을 했다. 보기 좋은 건 덤!

팀원분의 의견으로 'xml 주석 꼭 달아주기'를 추가해서 진행했다. 함수 위에서 /// 를 입력하면 자동으로 주석 틀이 생긴다. 함수 설명뿐만 아니라 매개변수나 반환값에 대한 설명도 모두 적을 수 있다. 기능이 점점 많아지면서 xml 주석이 실질적인 도움은 최고였다고 생각한다! 가장 대놓고 도움된 예시를 들자면, 팀원분께서 출력 관련 Utility 기능을 만들어주셨는데 종류가 아주 여러가지였지만 함수 하나씩 커서를 대보면 어떤 함수인지 바로 알 수 있었다. 엔진에 있는 기능 사용하듯이 물흐르듯 사용한듯!!

우리팀 노션 오른쪽에 대문짝만하게 있음

---

좋았던 점 3. 브랜치 적극 활용

23 브랜치과 3 태그

dev 브랜치를 개발의 주가 되는 브랜치로 쓰고, dev에서 뻗어서 기능들을 구현했다. main에 배포한다는 생각으로 만드니까 깔끔한 개발 단위가 생겨서 좋았다. main에 올리기전에 테스트 한 번하고 구조 안정화를 하니 기능 추가하면서 꼬이는 현상도 없고, 기능을 더 추가하기에 문제가 있는 코드는 미리 리팩터링하고 진행하니 전반적으로 막히는 부분이 없었다는 느낌이 들었다.

main에 세 번의 배포가 있었다!

---

좋았던 점 4. 팀 작업&회의 기록 남기기

일단 팀장으로서 허술하게 "우리 이제 뭐하지?" 라고 진행하고 싶지 않았다. 우선 기록을 남기며 하니 다음 날 작업을 이어할 때도 까먹고 넘어가는 일이 없어지고, 모두가 프로젝트 진행 상황을 이해하니까 소통 오류가 없었다. 이전에 어떠한 결정을 한 이유를 다시 확인해야 할 일이 있을 때도 너무 도움되고 고마운 존재였다.

그리고 다같이 정해야 하는 것이 있을 때 같은 의미를 공유하는지 체크하는 역할이 저절로된듯!? 이번엔 신기할정도로 소통 오류가 적었다! 

(마지막 날 깃허브 리드미까지 작성하며 기록 마무리했다)

팀플 시작 이후로 매일 figma나 노션을 작성했다.

 

그리고 팀원분들께서 이번 팀플은 매우 체계적으로 진행된 것 같다는 말씀을 하셨는데, 아마 문서를 많이 작성하고 공유하며 작업하니 그러지 않았을까? 라는 생각이 들었다. ㅎㅎ~

물론 매일 화상회의를 한 것도 도움 많이 됐을 것 같음

---

아쉬운 점 1. 도전 기능은 초기 계획만큼 설계하지 못하고 진행한 점 

초기 계획된 것들 이후에는 바쁘게 진행되다보니 클래스 계획 없이 진행되었다. 빨리 개발 시작해야 한다는 마음에 클래스 계획은 세우지 못하고 기획적인 계획 위주로 세우고 바로 진행했다. 그러다보니 서로 다른 사람이 만든 기능을 섞어야(?) 할 때 서로 생각했던 인터페이스가 달라 한 쪽이 수정해야 하는 일이 빈번했다.

계획이 없을 때는 코딩 협업이나 기능 병합이 힘들다는 반증이 되었다.! (ㄹ..럭키비키잔아) 

아쉬운 점 1-2. 후반에 계획이 없어서 빠른 일감 재분배가 어려웠다.

1번과 이유가 같기 때문에 1-2로 번호를 적었다. 나중에는 계획없이 새로운 기능을 추가하다 보니, 하던 작업이 끝난 팀원이 새로운 작업을 분배받으려면 알아서 만들 것을 찾아봐야 하는 현상이 생겼다. 5명이 모두 개발자이다보니 어느 한 명이 미리 기획을 정리하고 할 일을 나눠놓지 않아 발생한 문제라고 생각한다. 당시에는 다들 개발하기에 바빠서 다른 팀원의 작업을 생각해줄 여유가 없었지만, 미리 단체 회의를 한 번만 더 해놨다면 예방할 수 있지 않았을까!? 다음부터는 중간 회의도 자주 하는 것이 좋을 것 같다. 

---

협업 방식 외에 개인적인 아쉬움은 델리게이트를 많이 안써본 것이 아쉽다~ 다음 프로젝트에서는 활용해봐야지.! 그래도 해보고 싶던 json 파일 저장/로드는 체험해볼 수 있었어서 너무 좋았다.