2️⃣

9/2(월) 스크럼

FE

푸시 및 머지 관련 논의:
특정 요일과 시간을 정해 푸시와 머지를 진행하는 방안을 논의
매일 푸시와 머지를 하기보다는 월, 수, 금에 커밋하고, 토요일에 발생한 오류나 이슈를 멘토링 시간에 정리해 공유하자는 제안
커밋 시, 디스코드에 커밋 내용을 남겨 공유
브랜치 관리:
브랜치는 이슈별(기능별)로 생성하기로 결정
브랜치 생성 및 관리에 익숙하지 않다는 점을 고려하여, 푸시와 머지는 팀원이 모두 모였을 때 진행하는 것이 좋겠다는 의견
커밋은 로컬에 저장되며, 푸시를 해야 다른 사람들이 확인할 수 있음. 푸시 후 병합할 때 발생하는 오류는 디스코드에 공유하여 팀원들이 함께 해결할 수 있도록 하기로 함
프로젝트 진행 관련:
SignUp과 Post 관련 라우터 구조에 대해 논의. SignUp 폴더 내부의 파일 구조를 유지하되, 라우터는 SignUp과 Post 각각 하나만 남기고 나머지는 제거하기로 결정
Zustand를 사용하여 전역 상태 관리를 효율적으로 하기 위한 store 파일 관리 방법을 공유
Theme.ts에 정의된 색상 및 폰트 스타일을 공통으로 사용하여 디자인 통일성을 유지하기로 함
다음 작업:
팀원이 피그마에 정리한 내용을 확인하고 이해한 부분에 대해 서로 확인
특정 기능이 완료되면 해당 부분은 매일 커밋해도 괜찮다는 의견

BE

1. 도메인 중심 구조 논의:
도메인 중심으로 각 회원, 로그인, 게시판 단위로 컨트롤러, 서비스, 레포지토리 구성하는 방식
계층형 구조는 초기 프로젝트나 작은 규모에서 유리하지만, 유지보수나 확장성이 떨어질 수 있음
중대형 프로젝트에서는 도메인 중심의 구조가 더 일반적임 -> 도메인 중심 구조 채택
2. 브랜치 관리:
개인 브랜치를 생성하면 충돌 가능성이 높아질 수 있다는 의견
브랜치를 기능별로 나누고, 푸시와 머지는 모든 팀원의 승인을 받은 후 진행하기로 합의.
브랜치 명칭 제안: feature/sign-upfeature/loginfeature/passwordfeature/member
3. DTO 및 엔티티 네이밍:
DTO와 컨트롤러에는 접미사를 붙이고, 엔티티는 접미사 없이 이름만 사용하기로 함
DTO는 MemberRequestMemberResponse와 같이 별도 클래스로 구분
4. PR 및 이슈 관리:
PR은 작은 단위로 자주 하며, AS-IS와 TO-BE 형식으로 작성
이슈 템플릿도 설정하여 트러블슈팅 기록을 남길 예정
PR 시, 커밋 템플릿을 사용해 코드 변경 사항을 기록하고, 이슈 템플릿으로는 정상적으로 작동하지 않는 상황을 공유
5. 보안 및 설정 관리:
보안 설정 파일(yml 등)은 GitHub에 올리지 않고, 노션이나 구글 독스를 통해 공유하기로 함
개발 초기에는 JWT 기반 인증을 사용하고, 이후에 시큐리티를 적용하기로 합의
6. 회원 기능 개발 분담:
JWT 로그인 및 회원가입 구현
비밀번호 찾기 및 재설정 기능 개발
회원 정보 조회 및 수정 기능 구현
7. 백엔드 프로젝트 구조 논의:
기본 패키지 구조를 설정하면서 domain과 global로 나누기로 결정.
domain 패키지에는 기능별로 패키지를 만들고, 공용으로 사용하는 설정(config) 패키지는 global에 두기로 함
기본 패키지 구조를 설정하고 메인 패키지 이름을 com.onedrinktoday.backend로 수정
8. 클래스 및 패키지 구조 설정:
domain에 클래스와 레포지토리를 포함시켜 기능별로 관리할 예정
현재는 config를 포함한 기본적인 구조만 설정하고, 이후에 SwaggerConfig 등 필요한 설정 파일을 추가하기로 함
9. ERD 수정 사항:
삭제 여부를 boolean 값으로 관리하는 대신, deleted_at이라는 timestamp 필드를 추가하여 관리하기로 결정
이 방식은 deleted_at 필드가 null일 경우 삭제되지 않은 것으로, null이 아닌 경우 해당 시간에 삭제된 것으로 처리할 수 있어 더 유연함
이에 따라 ERD도 deleted(boolean)에서 deleted_at(timestamp)으로 수정하기로 함
10. 기타 논의 사항:
FE와 BE는 각각 배포하는 방식으로 진행