| 팀원 | 주요 담당 |
|---|---|
| 김태우 | 댓글 API 기능 담당 |
| 선혜린 | 리뷰 API 기능 담당 |
| 이종원 | 도서 API 기능 담당 |
| 최규원 | 사용자 API 기능 담당 |
| 한성태 | 알림 API 기능 담당 |
| 항목 | 기간 | 내용 |
|---|---|---|
| 기획 및 요구사항 정리 | 5/28 ~ 5/28 | 프로젝트 방향성 논의, 기능 리스트 작성 |
| 1차 개발 스프린트 | 5/29 ~ 6/9 | 프로토타입을 위한 기능 구현 시작 |
| 중간 점검 & 회고 | 6/9 | 프로토타입 기능 시연 + 피드백 수렴 |
| 2차 개발 스프린트 | 6/10 ~ 6/16 | 최적화, 테스트, 버그 수정, 배포 준비 |
| 발표 자료 준비 | 6/16~6/18 | 발표 자료 준비 및 오류 수정 |
| 최종 발표 & 회고 | 6/18 | 발표 자료 정리 및 시연 |
| 분류 | 사용 예정 도구 |
|---|---|
| Backend | Java Spring Boot, Lombok, Spring Data JPA, PostgreSQL, springdoc-openapi, QueryDSL, actuator, validation, jacoco |
| Database | Postgre Database, H2 |
| API 문서화 | Swagger |
| 협업 도구 | Discord, GitHub, Notion |
| 일정 관리 | GitHub Issues + Notion 타임라인 |
| 배포 도구 | AWS |
| 항목 | 내용 |
|---|---|
| 네이밍 컨벤션 | camelCase (변수, 함수), PascalCase (클래스), kebab-case (파일, URI), snake_case(DB 테이블명(복수형), DB 칼럼명, 외래키(fk_부모테이블_자식테이블), 유니크키(uq_부모테이블_자식테이블)) |
| 커밋 컨벤션 | feat(기능), fix(버그), refactor(패키지, 코드 로직 개선), docs(READ.md), style(변수명, 코드 이쁘게 개선), test, chore(의존성 추가) 등 |
| 브랜치 전략 | main, develop, fix/이슈번호 |
| Github workflow 전략을 쓰되, develop 브랜치를 만든다. | |
| PR 규칙 | 이틀마다 2명씩 돌아가면서 코드 리뷰를 한다. |
| 1명 이상 Approve 시 Merge | |
| 스크럼 | 오전 (9시 ~ 9시 10분) |
| 어제 무엇을 했고, 오늘 무엇을 할 것이다. | |
| 어제 PR 올렸지만 Merge 안 된 것은 무엇이 있고, 이슈상황은 이것이 있다. | |
| 코드 스타일 | 구글 표준 스타일 |
| 불참 | 불참 시 미리 공유, 불참자의 책임은 팀원이 대체 |
| 패키지 구조 | 도메인 중심 패키지 구조 |
프로젝트 준비 과정 또는 멘토링을 통해 발견된 잠재적 이슈들을 정리해 주세요.
멘토님의 피드백을 반영하거나 팀 논의를 통해 도출한 개선 포인트를 정리해 주세요.