[Sprint 백엔드 고급 프로젝트 1일차] 모두의 플리 프로젝트 시작
모두의 플리 프로젝트 시작!
오늘은 Spring Backend 고급 프로젝트 1일차다.
이번 프로젝트에서 우리 팀은 모두의 플리를 주제로 백엔드 서비스를 구현하게 되었다.
모두의 플리는 영화, 드라마, 스포츠 같은 다양한 콘텐츠를 평가하고, 사용자가 직접 플레이리스트를 만들어 공유할 수 있는 콘텐츠 큐레이션 플랫폼이다. 더불어 플레이리스트 구독, 알림, 팔로우, DM, 실시간 같이 보기 같은 소셜 기능도 포함되어 있다.
프로젝트를 시작하며…
첫날에는 Kick-off 미팅을 진행했다.
회의의 목적은 프로젝트를 본격적으로 시작하기 전에 팀원들이 같은 기준을 가지고 구현할 수 있도록 기본적인 협업 방식을 정하는 것이었다.
프로젝트 기간 동안 매일 오전과 오후에 회의를 진행하기로 했다.
- 오전 회의에서는 전날 개발했던 내용, 오늘 개발 목표, 컨디션을 공유한다.
- 오후 회의에서는 개발 진행 상황, 개인이 겪은 트러블 이슈, 팀 전체가 함께 논의해야 할 내용을 정리한다.
회의록은 한 사람이 계속 작성하지 않고, 팀원들이 돌아가면서 작성하기로 했다.
순서는 이다솔 ➡️ 전승주 ➡️ 박나경 ➡️ 박정현으로 정했다.
이렇게 매일 두 번씩 짧게라도 상태를 공유하면, 각자 어떤 작업을 하고 있는지 파악하기 쉽고, 혼자 막히는 시간이 길어지는 것도 줄일 수 있을 것 같다.
팀 규칙 정리
협업할 때 가장 중요한 것은 결국 소통이라고 생각해서 몇 가지 기본 규칙을 정했다.
서로 존중하고 화내지 않기, 적극적으로 소통하기, 불참해야 할 경우 최소한 전날 이야기하기, 메시지를 확인하면 체크 표시하기, 혼자 해결하기 어려운 문제가 생기면 팀원들에게 공유하기로 했다.
코드 컨벤션과 테스트 기준
코드 컨벤션도 간단하게 정리했다.
- 클래스 이름은
Pascal Case를 사용하고, - 변수와 메서드는
Camel Case를 사용하기로 했다. - 테스트 메서드 이름은
메소드명_기대결과_테스트상태형식으로 작성한다.isAdult_False_AgeLessThan18
TDD를 엄격하게 적용하지는 않기로 했다.
대신 기능 개발이 끝났다고 판단하려면, 해당 기능에 대한 테스트 코드까지 함께 PR에 포함해야 한다.
프로젝트 구조는 도메인 중심으로
프로젝트 구조는 도메인 형식 구조로 정했다.
Member
┣ controller
┣ service
┗ dto
Order
┣ controller
┣ service
┗ dto
도메인별로 패키지를 나누면 내가 맡은 기능과 다른 팀원이 맡은 기능의 경계가 비교적 명확해진다.
이번 프로젝트처럼 여러 명이 동시에 개발하는 상황에서는 기능 단위로 코드를 찾기 쉽고, 충돌도 줄일 수 있을 것 같아서 이 구조를 선택했다.
공통으로 사용하는 코드는 common 패키지에 두기로 했다.
예외 처리와 공통 Entity, DTO, 로그 관련 설정 등이 여기에 들어갈 예정이다.
Git 브랜치 전략과 PR 방식
브랜치 전략은 Git Flow를 사용하기로 했다.
main은 최종 완성본을 관리하고, develop은 구현이 끝난 기능들이 모이는 브랜치로 사용한다.
개별 기능 개발은 feature/이슈번호-간단한 설명 형식의 브랜치에서 진행하고, 배포 환경 관련 작업은 release 브랜치를 활용하기로 했다.
PR은 가능한 한 세분화해서 올리기로 했다.
하나의 PR에 너무 많은 변경사항이 들어가면 리뷰하기 어렵기 때문이다.
PR을 올릴 때는 설명, 관련 이슈, 변경 유형, 체크리스트, 추가 설명을 작성한다. 관련 이슈는 Closes #1과 같은 형식으로 연결한다.
PR 리뷰는 디스코드 스레드를 통해 구현한 사람과 리뷰어가 소통하기로 했다. PR이 merge된 후에는 단체방에 공지하고, 팀원들이 확인 표시를 남기기로 했다.
1일차에 정한 추가 개발 기준
회의를 하면서 세부적인 개발 기준도 몇 가지 정했다.
먼저 Service는 별도의 인터페이스로 분리하지 않기로 했다.
반면 Controller는 API 문서화를 고려해서 인터페이스를 분리하고, 도메인ControllerDocs 형태로 관리하기로 했다.
DTO 패키지는 request와 response를 분리한다.
이렇게 나누면 요청 데이터와 응답 데이터의 역할이 명확해지고, API가 많아졌을 때 관리하기 쉬워질 것 같다.
로깅은 Controller에는 두지 않고, 필요한 경우 Service 또는 Batch 쪽에 두기로 했다.
또한 의존성 있는 Entity는 해당 도메인 담당자가 구현하기로 했다.
만약 내가 구현하는 기능에서 아직 만들어지지 않은 다른 도메인의 Entity가 필요하다면, 임시로 주석이나 TODO를 남겨두고 해당 도메인 담당자가 구현하는 방식으로 진행하기로 했다.
전체 역할 분담
프로젝트의 역할 분담도 마무리했다.
- 사용자 관리와 인증, 프로필 정보는 박나경님이 담당한다.
- 콘텐츠 데이터와 리뷰, 실시간 같이 보기 기능은 전승주님이 담당한다.
-
프로필, DM, 팔로우는 이다솔님이 담당한다.
- 내가 맡은 부분은 플레이리스트와 알림이다.
- 알림에서는 SSE 연결도 함께 담당하게 되었다.
요구사항 정의서
역할 분담이 완료되고 요구사항 정의서를 작성했다.
팀 Notion 주소
[SB10-4팀] Sprint Spring 백엔드 고급 팀 프로젝트
Leave a comment