피드백 정리
역할 관련
•
모두가 같은 도메인을 나눠서 진행하기는 어려울 듯
•
연관되어있는 기능들은 2~3명으로 나눠서 하나의 도메인 작업 진행하는 것도 괜찮음
시나리오 관련
•
유스케이스는 충분히 디테일하게 잘 작성되었음
•
작성한 기능들이 지금까지 한것과 다를게 없어서 아쉬운 부분은 있음
•
MVP 자체는 괜찮은데 +a 기능들이 있으면 좋을듯 (확장성 고려)
◦
서비스 출시를 고려했을 때 필요한 기능들을 더 생각해볼 것
◦
ex) 관리자 기능, 채팅방, 기술스택
API 명세 관련
•
명세서 상단에 모든 응답에는 어떤 값들이 포함되어 있는지 명시하면 좋음
•
모집글 전체 조회는 하나의 api로 통합하는 것이 좋음
◦
ALL, 본인 작성, 신청, 좋아요, 승인된, 기술스택, 직군
◦
service layer에서 로직을 나누는 방식(ex.모집글 조회를 각각 다 다른 메서드로 작성. 현재 기준 6개)
▪
메서드별 공통적으로 포함되는 로직을 찾아서 통합 후 분기 처리. case를 나눠서 진행.
◦
이후 리펙토링할 것
◦
타입을 enum으로 관리
•
기능 구현시 테스트를 여러 번 하는 것이 좋음
ERD 관련
•
모집글과 기술스택 배열 형태로 저장 vs 테이블 분리
◦
기술 스택 자체가 데이터가 많지 않아서 성능의 차이는 미세할 듯
◦
1NF 원칙에 따라 하나의 컬럼에 하나의 값만 가질 수 있도록 테이블 분리하는 것이 좋을듯
•
직군별 모집인원
◦
모집글 테이블에서 관리 (테이블 분리 x)
▪
프로젝트마다 모집 직군이 다름 → 좋지 않은 방법(일일이 컬럼 생성해야 하므로)
▪
ex) 웹 프로젝트(BE, FE, Designer), 앱 프로젝트(BE, Android, iOS, Designer)
◦
테이블 분리해서 관리하는게 좋을듯
◦
히스토리성 테이블?
▪
테이블 변경되는 걸 일일이 기록하는 테이블.
▪
직군별 모집인원 변동사항 있을시(ex. BE 3명, FE 2명 → BE 2명, FE 2명) 별도의 테이블로 기록을 쌓아서 관리
정리
•
MVP 이외의 기능 생각해볼 것
◦
기능 추가 시에도 구조의 변경이 최소화되도록
◦
현재는 채팅 1:1만 존재
◦
이후 단톡방 고려해서 설계해볼 것
피드백 반영
역할 관련
•
현행 유지
시나리오 관련
•
현행 유지
API 명세 관련
•
restdocs 링크 첨부
•
모집글 전체 조회는 하나의 API로 압축
◦
관련 카테고리는 enum으로 관리
ERD 관련
•
채팅방 테이블 추가
