[팀 프로젝트] TALKAK ERD, API 문서, 프로젝트 수행 규칙들

이전 글에 이어서 써보겠다. 기획 과정이 궁금하다면 밑의 링크 참고하길 바란다.

https://yjhan1999.tistory.com/14

[TTALKAK] 프로젝트 기획 과정

 

기획이 끝났으니까 구체적인 개발 과정에 들어간다.

우선적으로 기능 구현 이전에 유저 페르소나 및 시나리오를 구성해보고 필요한 Entity와 연관관계를 생각해봤다.

 

1. ERD

우선 최종적으로 설계한 내용부터 보여드리겠다

ERD

백엔드 팀원들과 ERD를 구성하면서 초기 설계의 중요성을 느꼈다. 그리고 생각보다 까다로웠다. 어떤 관점에서 보면 다대다 연관관계가 맞는거 같기도하고, 다른 관점에서 아닌 거 같은 경우도 있었다. 그리고 테이블명의 복수/단수에 대한 문제, 테이블을 분리하는 과정 등등 어려웠다. 솔직히 마지막에 가독성 좋게 ERD 표를 그리는 것이 젤 어렵긴 했다ㅋㅋ 역시 디자인은 내 적성에 안맞다.

 

테이블은 크게 Member, Category, Comment, Video, Keyword, Reaction이 있었고 다대다 관계를 위한 Member_category, Video_keyword도 추가했다. 

 

2. API 명세서

API 문서는 프론트와 백엔드 같이 상의하며 작성했다. 당연한 이야기지만 프론트와 백엔드의 협업을 위해서라면 API 문서가 없어서는 안된다. 프론트에서 원하는 바와 백엔드에서 원하는 형식이 살짝 다를 때도 있었는데, 그 때는 의논을 잘해서 잘 마무리한 것 같다. 그리고 개발하면서 조금 변동사항이 있으면 팀원들에게 말해서 다시 API 문서를 조금씩 수정하면서 개발을 진행했다.

최종 작성한 API 문서이다. 여기서는 스크린샷으로 올렸기 때문에 안보이지만 각각의 기능에 들어가면 Header, Request, Response, Error에 대한 형식이 작성되어있다. 개발하면서 느꼈지만 API 명세서를 잘 정리해놓으니까 편했다.

 

 

3. Git 작업단위

- 브랜치 전략

• week : 주차별 개발 작업할 때 쓴 브랜치이다.
• review : 주차별 개발한 작업물을 멘토님에게 리뷰를 받는 브랜치이다.
• develop : 리뷰 받은 내용 토대로 리팩토링 후 오류 없는지 확인하는 브랜치이다.
• master : 최종 브랜치 -> 배포용이다.

따라서 한주가 시작될 때마다 새로운 week 브랜치를 파고 작업한 후에 review 브랜치에서 리뷰를 받고 다시 week 브랜치에서 리팩토링을 한 후 develop 브랜치로 머지. 오류가 없으면 master 브랜치로 머지하는 방식이다. 브랜치 전략을 써서 프로젝트를 해보는게 처음인데 굉장히 오류 수정하기도 좋고, 각 주차별로 했던 내용을 볼 수 있어서 정말 편했다. 

 

- 이슈 템플릿

조장님이 쓰시던 템플릿을 가져와서 조금 각색해서 사용했다. 이슈에서 각자 개발할 내용 및 오류 내용을 적고 그거에 맞게 코드 작성 후 이슈 기반 PR을 날리기로 결정!

 

- 이슈 네이밍

• feature: 새로운 기능에 대한 커밋
• build: 빌드 관련 파일 수정에 대한 커밋
• chore: 그 외 자잘한 수정에 대한 커밋 (기타 변경)
• docs: 문서 수정에 대한 커밋
• design: 코드 스타일 혹은 포맷 등에 관한 커밋 (프론트엔드 같은 경우 CSS, 백엔드분들 코드 스타일이나 포맷)
• refactor: 코드 리팩토링에 대한 커밋
• test: 테스트 코드 수정에 대한 커밋
• fix: 버그 수정 관련한 커밋
• rename: 파일 이동, 파일 이름명 변경할 경우
• env: 개발환경 세팅

이거 기반으로 커밋 컨벤션도 비슷하게 정했다.

그리고 각 파트별로 코딩 컨벤션도 정했다. 보통 사용하는 Google Java Style Guide를 토대로 결정했다.

 

다음 주부터는 정말로 개발 시작

다음 편으로 돌아오겠슴니다.