Dev 미니 프로젝트 개요

• 기간 : 4주 (3/26~4/30)
  • 3/26 ~ 4/2 (1주차)
  • 4/2 ~ 4/9 (2주차)
  • 4/9 ~ 4/16 (3주차)
  • 4/16 ~ 4/30 (4주차)
  • 4/30 (최종발표)
• 구성 : 백엔드 1명, 프론트엔드 2명
• 목표 : 실제 프로젝트 투입 전, 기획부터 배포까지의 전체 흐름(End-to-End)를 경험하고, 협업 툴(피그마, 노션, 깃허브, 스웨거) 등을 사용해보며 협업 역량을 기릅니다.
  • 프론트엔드는 각자 1개 씩 구현하는것을 목표로 합니다.
  • 본 프로젝트의 우선순위는 '완성' 그 자체보다 '협업의 과정'에 있습니다.
  • 기술적 숙련도보다 동료와 어떻게 소통하고, 그 과정을 어떻게 기록으로 남기는지에 집중해 주시기 바랍니다

기술 및 협업 요구사항

• 코드 관리 : GitHub 사용 필수

  • GitHub Commit Convention 적용
    • 관련 글 : https://velog.io/@shin6403/Git-git-커밋-컨벤션-설정하기
  • PR (Pull Request)를 통한 목표 추적 및 Merge 프로세스 준수
    1. GitHub에서 issues 생성
    2. issues에서 branch 생성
    3. branch에서 작업 후 commit & push
    4. PR (Pull-Request) 작성
    5. main branch로 merge

• 일정 및 목표 관리

  • 기획서, API 명세서 등 프로젝트 문서화 필요

  무엇을 하더라도 반드시 문서화 하는 습관을 기르시면 좋겠습니다

  문서화되지 않은 프로젝트는 설계도 없이 쌓아 올린 건물과 같습니다.

  프로젝트는 시간이 지남에 따라 필연적으로 규모가 커지며, 초기의 설계 의도는 망각되기 쉽습니다. 문서화는 이를 방지하는 유일한 수단입니다.

  발생한 이슈와 해결 과정을 기록함으로써 동일한 문제의 재발을 막고 기술적 자산으로 축적합니다.

  프로젝트를 진행하면서 문서화한 정보는 추후 이력서나 면접 준비 시에 유용하게 활용할 수 있습니다.

기능 요구사항 정리

공통 기능 (Core CRUD)

• 할 일 추가 : 내용, 날짜, 카테고리를 입력받아 저장합니다.
• 할 일 조회 : 저장된 모든 할 일을 리스트 형태로 불러옵니다.
• 할 일 수정 : 등록된 할 일의 내용이나 카테고리를 변경합니다.
• 할 일 삭제 : 특정 할 일을 삭제합니다.

파트별 집중 과제

• Backend
  • RESTful API 설계 및 Swagger를 통한 문서화
  • DTO 구조 설계 및 유효성 검사 (Validation)
• Frontend
  • 페이지 라우팅 설계 : 사용자가 URL에 따라 어떤 화면을 보게 될지 구현
  • 비동기 데이터 처리 : 백엔드 API와의 통신 설계
  • 피그마 활용 : 피그마 디자인을 실제 코드로 구현