개별과제 : JPA를 사용한 일정 관리 앱 만들기 (+ 트러블슈팅)

🥊 과제를 시작하며 남기는 회고

이전 과제와 작은 변화가 있다면 데이터베이스 연결을 처음으로 시도해보았고 이전보다 시작을 해볼 수 있었음에 조금 기쁘면서도, 해내지 못한 부분이 더 많다는 좌절감이 크게 남았다. 큰 이슈 없이, 입문과제도 못해냈다는 좌절감에 오랜시간 패닉을 겪은 것 같다. 이번 숙련과제는 단순히 내 자신감 부족과 이미 늦어버린게 아닐까 하는 생각으로 내려놓은 내 잘못된 패턴으로 인해 작업을 마무리하지 못했다.

수요일부터 목요일까지 하나씩 마주하며 다시 살펴보고 강의노트를 살펴보며 따라해보니,
크게 어려워하지 않아도 되었던 일임을 깨달았고, 잘못된 생각들로 시간을 낭비했다는 생각이 들었다.

스스로 해내는 것만이 뿌듯한 일이 아니라는 것을 알게 되었고 답이 안나올 때에는 Google이나 ChatGPT에 의존하는 것이 아니라 튜터님들께 여쭤보는 것이 좋다는 것을 깨달았다.

점심을 먹다가 알고리즘으로 인해 보게된 성실한데 성과 못 내는 개발자 특징 Youtube 영상을 보고 확실하게 깨달았다.

✅ 작업 기록

0️⃣ 단계 : API 명세 및 ERD 작성

1️⃣ 단계 : 일정 CRUD

❗ 필수 기능 가이드

• 일정을 생성, 조회, 수정, 삭제할 수 있습니다.
• 일정은 아래 필드를 가집니다.
  • 작성 유저명, 할일 제목, 할일 내용, 작성일, 수정일 필드
  • 작성일, 수정일 필드는 JPA Auditing을 활용합니다. → 3주차 JPA Auditing 참고!

CalendarCreateRequestDto을 생성하는 과정에서 Getter 형식이 2가지가 있어서 어떤 형식이 더 좋은지 궁금해져서 알아보았다.

내가 처음 작성한 Getter는 아래와 같았고

public class CalendarCreateRequestDto {
    private String name; // 작성 유저명
    private String title; // 할일 제목
    private String description; // 할일 내용
    private String date; // 작성일
    private String modify; // 수정일

    public String getName() {
        return this.name;
    }

}

인텔리제이에서 추천해준 Getter는 아래와 같았다.

public class CalendarCreateRequestDto {
    @Getter
    private String name; // 작성 유저명
    private String title; // 할일 제목
    private String description; // 할일 내용
    private String date; // 작성일
    private String modify; // 수정일
}

밤에는 조언을 구하기 어려워서 chatGPT에게 어떤 형식이 좋은 형식인지 질문해보았다.
Getter 관련 내용 정리로 따로 작성해놓았는데 상황에 따라 적재적소에 사용해야하는 메소드라는 생각이 들었다.

---

2️⃣ 단계 : 일정 수정 및 삭제

❗ 필수 기능 가이드

• 선택한 일정 수정
  - 선택한 일정 내용 중 할일, 작성자명 만 수정 가능
  - 서버에 일정 수정을 요청할 때 비밀번호를 함께 전달합니다.
  - 작성일은 변경할 수 없으며,수정일` 은 수정 완료 시, 수정한 시점으로 변경합니다.
  
• 선택한 일정 삭제
  • 선택한 일정을 삭제할 수 있습니다.
    • 서버에 일정 수정을 요청할 때 비밀번호를 함께 전달합니다.

---

3️⃣ 단계 : 연관 관계 설정

❗ 필수 기능 가이드

• 작성자와 일정의 연결
  • 설명
    • 동명이인의 작성자가 있어 어떤 작성자가 등록한 ‘할 일’인지 구별할 수 없음
    • 작성자를 식별하기 위해 이름으로만 관리하던 작성자에게 고유 식별자를 부여합니다.
    • 작성자를 할 일과 분리해서 관리합니다.
    • 작성자 테이블을 생성하고 일정 테이블에 FK를 생성해 연관관계를 설정해 봅니다.
  • 조건
    • 작성자는 이름 외에 이메일, 등록일, 수정일 정보를 가지고 있습니다.
      • 작성자의 정보는 추가로 받을 수 있습니다.(조건만 만족한다면 다른 데이터 추가 가능)
    • 기존 : 고유 식별자를 통해 작성자를 조회할 수 있도록 기존 코드를 변경합니다.
      • 변경 : 작성자의 고유 식별자를 통해 일정이 검색이 될 수 있도록 전체 일정 조회 코드 수정.
    • 작성자의 고유 식별자가 일정 테이블의 외래키가 될 수 있도록 합니다.

---

4️⃣ 단계 : 페이지네이션

❗ 필수 기능 가이드

• 설명
  • 많은 양의 데이터를 효율적으로 표시하기 위해 데이터를 여러 페이지로 나눕니다.
    • 페이지 번호와 페이지 크기`를 쿼리 파라미터로 전달하여 요청하는 항목을 나타냅니다.
    • 전달받은 페이지 번호와 크기를 기준으로 쿼리를 작성하여 필요한 데이터만을 조회하고 반환
• 조건
  • 등록된 일정 목록을 페이지 번호와 크기를 기준으로 모두 조회
  • 조회한 일정 목록에는 작성자 이름이 포함
  • 범위를 넘어선 페이지를 요청하는 경우 빈 배열을 반환
  • Paging 객체를 활용할 수 있음

---

5️⃣ 단계 : 예외 발생 처리

❗ 필수 기능 가이드

• 설명
  • 예외 상황에 대한 처리를 위해 HTTP 상태 코드(링크)와 에러 메시지를 포함한 정보를 사용하여 예외를 관리할 수 있습니다.
    1. 필요에 따라 사용자 정의 예외 클래스를 생성하여 예외 처리를 수행할 수 있습니다.
    2. @ExceptionHandler를 활용하여 공통 예외 처리를 구현할 수도 있습니다.
    3. 예외가 발생할 경우 적절한 HTTP 상태 코드와 함께 사용자에게 메시지를 전달하여 상황을 관리합니다.
• 조건
  • 수정, 삭제 시 요청할 때 보내는 비밀번호가 일치하지 않을 때 예외가 발생합니다.
  • 선택한 일정 정보를 조회할 수 없을 때 예외가 발생합니다.
    1. 잘못된 정보로 조회하려고 할 때
    2. 이미 삭제된 정보를 조회하려고 할 때

---

6️⃣ 단계 : null 체크 및 특정 패턴에 대한 검증 수행

❗ 필수 기능 가이드

• 설명
  • 유효성 검사
    1. 잘못된 입력이나 요청을 미리 방지할 수 있습니다.
    2. 데이터의 무결성을 보장하고 애플리케이션의 예측 가능성을 높여줍니다.
    3. Spring에서 제공하는 @Valid 어노테이션을 이용할 수 있습니다.
• 조건
  • 할일은 최대 200자 이내로 제한, 필수값 처리
  • 비밀번호는 필수값 처리
  • 담당자의 이메일 정보가 형식에 맞는지 확인

---

❓ 과제 제출시에는 아래 질문을 고민해보고 답변 작성

1. 적절한 관심사 분리를 적용하셨나요? (Controller, Service, Repository)

2. RESTful한 API를 설계하셨나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?

3. 수정, 삭제 API의 request를 어떤 방식으로 사용 하셨나요? (param, query, body)

---

🛠️ 문제 해결 X 회고

작업 후기

소요시간 : 아직 알 수 없음
난이도 : 상

>> Java : JDBC를 사용한 일정 관리 앱 만들기 GitHub Code 바로가기
다 만들어진 코드는 위의 깃허브에 올려놓았다.