• 부제목 - 시간은 왜이렇게 빠른거야?!

이번주차는 1주일간 협업프로젝트를 했다.
아직 프로젝트가 끝나지 않았지만 배운것도 많은만큼, 힘들기도 했던 한주였다.

프로젝트 준비

아무래도 많은 분들이 협업이 처음이시다 보니 준비하는 과정이 꽤나 길었다. 프로젝트 주제 선정 / api명세서 작성 / sa노션 작성 / 와이어프레임 작성 / erd작성 등 여러 준비를 마무리 하는데 시간이 예상보다 많이 소요되었다.

하지만 이번프로젝트를 진행해보면서 앞으로 다음 프로젝트에는 어떻게 하면 더 완벽하게(?) 준비할 수 있을지 알 수 있게 되었던 것 같다.

개발 환경

우선 우리팀은 내가 Github에서 organization을 생성하여 프로젝트를 시작했다. 하지만 이제 vercel은 organization에 위치한 repository를 배포하려면 pro계정으로 전환을 하여 유료서비스가 되었기 때문에 어쩔 수 없이 우선 내 깃허브에 repository를 생성해서 시작하였다.

이후 prettier와 eslint를 사용해서 기본 코드 컨벤션을 만들고, 기본적인 router 설정과, 폴더 구조를 잡고 각자 개발을 시작했다.

우리팀의 컨벤션

우리는 커밋 컨벤션과, branch 전략정도를 세우고 시작했다.
우선 커밋 컨벤션은 가장 기본적으로 많이들 사용하는 규칙을 사용하였다.

FEAT :	기능 개발 및 기능 추가
FIX :	버그 수정
DESIGN :	UI 디자인 변경
!BREAKING CHANGE :	커다란 API 변경의 경우(URI 주소 외 Request, Response 가 변경되는 경우)
!HOTFIX :	급하게 치명적인 버그를 고쳐야하는 경우
STYLE :	코드 포맷 변경, 세미 콜론 누락, 코드 수정이 없는 경우
REFACTOR :	코드 리팩토링
TEST :	테스트 코드, 리펙토링 테스트 코드 추가, Production Code(실제로 사용하는 코드) 변경 없음
MERGE :	병합
CONFLICT:	병합 시 충돌 해결
DEPLOY :	배포 관련 커밋
REMOVE :	파일을 삭제하는 작업만 수행한 경우
RENAME :	파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우

branch전략 또한 git-flow전략을 사용하여 main devleop feature/개발환경 의 브랜치를 생성하여 작업하였다.

확실히 협업 경험이 적다보니, 컨벤션을 정하고 시작했다고 생각 했지만, 많은 부분이 부족했던것 같다.

예를들어 폴더 구조화 방식이 확실히 개인마다 다르다는 것이 느껴졌다.

느낀점

정신없이 1주일이 지났지만 힘들었던 만큼 팀원분들과 소통을 많이 하면서 돈독해졌다는 것을 느꼈다. 백엔드 분들과 소통을 하면서 백엔드 지식도 조금씩 알게 되다 보니, 소통하면서 협업하는 과정이 재미있었던것 같다. 그럼에도 부족한점들이 많았기 때문에 차차 보완해나가서 마지막 파이널 프로젝트에서는 완벽에 가까운 프로젝트를 해보고 싶다!

정말 정신없었던 일주일이었지만 그만큼 많은것을 배우고 깨달을 수 있는 시간이었다고 생각한다.