피드백 정리

역할 관련

• 모두가 같은 도메인을 나눠서 진행하기는 어려울 듯
• 연관되어있는 기능들은 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명) 별도의 테이블로 기록을 쌓아서 관리