2023년 9월 회고 (프론트엔드 데브코스 회고)

https://github.com/prgrms-fe-devcourse/FEDC4_Campers_Jaeho

9월은 팀 프로젝트를 하는 달이었다. 인생을 살면서 첫 프로젝트이기도 하고, 팀장도 처음으로 맡아서 하게 되었다. 개발 더 나아가 인생을 살면서 잊지 못하는 순간 중 하나라는 생각이 든다. 다사다난했던 한 달이었기 때문이다. 기술적인 측면보다는 경험적인 측면에서 회고를 해보려고 한다.

개발에 대한 회고

좋았던 점

• 초기 설정 (husky, prettier, eslint, lint-staged, commitlint, github)
• axios (auth)
• auth page 및 회원가입
• 컴포넌트 공통화, alert-dialog 창, tabs 창
• context API (userInfo)

크게 위와 같이 나누어진 task를 수행했다. 맡은 부분에서 책임지고 해내고 싶었는데 그 기대에 맞게 잘 동작하게 해낸 것 같아 다행이었다.

아쉬웠던 점

추가 구현사항인 채팅 기능을 구현하고 싶었는데 일정상 하지 못했던 것이 아쉽다.

협업 방식에 대한 회고

좋았던 점

github의 칸반보드를 잘 활용하고 issue, PR, git commit message를 생성하는데 필요한 convention을 팀원들과 회의를 통해 만들었고, 개인적으로 앞에서 명시된 사항들을 잘 지켰다.

아쉬웠던 점

팀원들 간의 역량 편차로 인해 개인적으로 코어 타임에는 주로 코드 리뷰를 진행하고, 코어 타임이 끝난 후 기능을 구현하게 되었는데, 기능 구현보다 코드 리뷰에 치중된 것 같아 아쉬웠다.

비동기적인 소통이 강조되지만, 동기적인 소통이 필요한 상황이었다.

프로젝트 초기, git과 gitHub에 대한 충분한 설명과 문서를 제공했지만, 현실은 이와 다르게 진행되었다. 팀원 중에서는 이해를 했다고 의사를 표명했지만, 실제로는 반대인 경우가 있었다. 나아가 노트북 세팅 문제나 git에서의 오류 등 다양한 문제가 발생했다.

github 이슈 및 PR의 제목과 내용 형식에 대한 규칙을 정했지만, 이를 따르지 않는 팀원도 있었다. git commit message 또한 성의 없이 올린 팀원도 있어서, 충분한 설명과 이유를 포함해 규칙이 잘 지켜지지 못한 것에 대해 지키자는 이야기를 많이 했었다.

위 명시된 사항들을 팀원들에게 알려주고, 해결하기 위해 생각보다 많은 시간을 할애했다.

에러가 난 채로 PR이 올라와진 경우가 많이 있었고, 에러가 있는 채로 review가 진행되고 merge가 된 경우가 많이 있었다. 즉 에러가 있는 채로 main으로 merge가 되는 것이다. 이 점이 아쉬웠다.

앞으로는

프로젝트를 설정할 때 github actions를 활용해서 build 실패 시 merge가 되지 못하도록 하는 장치를 추가해야겠다. 더 나아가 husky의 pre-push 파일을 만들어 git push를 하기 전 build를 하도록 하고 실패하면 push가 되지 못하도록 해야겠다.

github wiki 혹은 notion에 프로젝트에 대한 것을 더 자세히 기록해야겠다. 누군가는 당연히 알고 있고 충분한 설명을 듣고 이해했다고 하더라도, 실제로는 그렇지 않은 사람이 존재할 것이고, 물어보기를 망설일수도 있을 것이다. 모든 사람이 말을 하기를 좋아하고 잘 하는 것은 아니기 때문이다. 그래서 모든 내용을 문서화할 필요성을 느꼈다.

전체적인 룰은 정하고, 태스크를 1차, 2차로 나누어 1차 태스크는 공통적으로 분배하고 2차 태스크는 개개인의 역량을 존중하기 위해 1차 태스크를 완료한 팀원이 가져가는 식으로 진행이 되었다. 예상했던 것과 다르게 1차 태스크가 마감에 근접했지만 완료되지 못하는 상황이 발생하기도 했다. 이에 대해 팀원간의 신뢰가 있고, 편차가 크지 않을 경우 가능하다는 생각을 하였다. 다음에는 상황에 맞게 일정을 계획하고 개인의 역량에 맞게 수시로 태스크를 재분배해 진행하면 좋겠다는 생각을 했다.