[부트캠프 과제] 일정 관리 앱 만들기

깃허브 링크

https://github.com/ethrad/Schedule

GitHub - ethrad/Schedule

---

API 명세서

https://documenter.getpostman.com/view/38617071/2sAXxLCujS

일정 관리

---

DB 다이어그램

---

클래스 다이어그램

---

회고

• 과제를 하면서 3 Layer Architecture를 이해할 수 있었다.

강의를 볼 때는 개념이 흐릿하게 있었는데 직접 만들어보니 확실히 이해할 수 있었다.

 

• Response DTO, Request DTO를 사용하는 이유를 알 수 있었다.

강의에서는 사용하는 객체가 너무 간단해서 DTO를 사용하는 이유를 잘 이해하지 못했는데 과제를 하면서 이해할 수 있었다.

 

• 프론트엔드 페이지 만들 시간에 도전 과제를 할 걸....

GPT한테 프론트엔드 페이지 만들어달라고 했는데 제대로 작동은 안 하고 오류 고치느라 시간만 낭비했다.

지금도 제대로 작동 안 해서 포기했다.

다음 과제는 프론트 없이 만들고 postman으로 요청 보내서 확인해야겠다.

 

• 테스트 기능을 활용하지 못한 점이 아쉽다.

postman으로 요청 보내고 오류 나면 고치고 했는데 지금 생각해보니 테스트 기능으로 먼저 해볼 걸 그랬다.

특히 DB 사용하는 부분이 오류가 자주 나고 헷갈리는데 테스트를 먼저 하면 시간을 아낄 수 있을 것 같다.

 

• 개발을 먼저 하고 API 명세서를 작성했다.

Spring을 처음 다뤄보는 거라 강의에 있던 코드를 많이 활용해서 만들었다.

그래서 복붙하면서 코드를 먼저 작성했는데 다음 과제에서는 API 명세서를 먼저 작성해야겠다.

 

• ERD 작성을 안 했다.

근데 도전 과제를 안 했더니 테이블이 한 개 밖에 없었다. 다음에는 도전과제까지 해야지.

 

• 다 하고 나니 그렇게 어렵지 않았다.

역시 프론트를 버리고 도전 과제를 했어야 했다.

 

• 같은 의미의 용어를 다르게 적게 되는데 이게 엄청 중요한지 모르겠다.

createAt을 한국어로 적을 때 만든 날짜, 생성 날짜 이런 식으로 다르게 적게 되는데 문제가 있는지 궁금하다.

팀에서 일을 한다면 용어 정리를 하고 개발할 것 같긴 하다.

 

A. 팀 내에서 변수에 대한 통일과 이를 팀내 언어로 만드는것은 매우 중요합니다.
다만, 이번엔 1인 프로젝트이고 작은 규모이기에 지금은 크게 중요하지않다고 생각합니다.
예를 들어 쿠팡 시스템을 만들었는데, 누구는 상품을 아이템이라 부르고 누구는 상품이라 부르면 대화에 대한 비용이 추가됩니다. 
이렇기에 용어 통일은 매우 중요합니다.

 

• 커밋이 섞여있을 때 풀 리퀘스트를 어떻게 작성해야 하는가?

커밋에 기능 추가랑 버그 수정, 리팩토링 등이 섞여있는데 이러면 풀 리퀘스트를 어떤 식으로 작성해야할지 모르겠다.

 

A. 네 PR은 주기적으로 최대한 작은 단위의 커밋으로 하는것이 좋습니다.
PR을 한다는것은 리뷰를 받기위함인데 리뷰어 입장에서 커밋의 양이 방대해지면 리뷰에 대한 피로도가 증가하고 버그 식별을 잘 할 수 없게됩니다.
말씀하신대로 작은 단위의 커밋 이 후 PR을 하는것이 맞습니다.

---

[완성도에 대한 피드백]

1. Optional 학습 제안
    public ScheduleResponseDto getSchedule(Long id) {
        // 해당 일정이 DB에 존재하는지 확인
        Schedule schedule = scheduleRepository.findById(id);
        if (schedule != null) {
            return new ScheduleResponseDto(schedule);
        } else {
            throw new IllegalArgumentException("선택한 일정이 존재하지 않습니다.");
        }
    }
위와 같은 코드는 Java의 Optional을 학습하면 if else 절 없이
scheduleRepository.findById(id).orElseThrow(...) 방식으로 한줄로 처리할 수있습니다.
Optional은 자바에서 꽤나 유용하게 많이 사용되는 키워드이니 학습을 추천드립니다.

2. 커스텀 예외 처리 제안
현재 IllegalArgumentException를 사용하여 예외를 던지고있는데, 보다 더 직관적인 예외(Exception)을 정의하여 던지면 왜 API 요청이 실패했고 어떤 문제가 있는지 명확히 식별할 수 있게됩니다.
다음 프로젝트엔 CustomException을 정의하여 명확한 예외를 던질 수 있도록 만들어보는것을 추천드립니다.
구글에 spring custom exception을 입력하면 많은 자료들이 나올꺼에요.

3. ERD 명세 작성
현재 ERD 작성이 되어있지않은것같은데 맞을까요? (찾지못했어요)
현재 테이블 구조가 단순하여 필수이진 않겠으나 다음 프로젝트부턴 연관관계가 형성될것인데 이를 ERD로 추출하여 관계를 이해할 수 있도록 만들어보시는것을 추천드립니다.

 

---

실시간 강의 정리

• optional 사용해서 null 객체 판별하기
  
  DTO가 너무 많은 계층을 관통했다
  DTO를 각 계층마다 나눠서 사용해야함
  Client - [DTO1] - Controller - [DTO2] - Service - [DTO3] - Repository - DB
  
  DTO1 : Request/Response
  DTO2 : Command
  DTO3 : DomainDTO/Entity

 

• Service 코드 만드는 데에 집중하기

 

• early return 사용하기
  if 문 사용해서 return이나 throw를 먼저 하기

 

• customException으로 에러 메시지를 맞게 전달
  ErrorResponse 클래스 만들어서 CustomErrorCode, description, detail 변수 넣고 ErrorResponse를 전달하는 방식으로?

 

• schedule.getPassword.equals(requestDto.password())
  -> 이런 거는 Entity한테 위임해서 설명적인 코드만 남도록 하는 게 좋음

 

• String updateDate = String.valueOf(LocalDateTime.now());
  scheduleRepo.update(id, ~, updateDate)
  -> 설명적이지 않음, 단위 테스트 작성을 어렵게 하는 코드이다
  -> schedule.updateLastUpdatedTime(LocalDateTime.now()); 로 수정

 

• delete할 때 id를 넘기지 말고 schedule을 통째로 넘겨라

 

• 익명 객체 대신 람다 표현식 사용

 

• lombok으로 생성자 생략하기

 

• 정적 팩토리 메소드 이용하기
  ScheduleResponseDto.from(schedule)
  이펙티브 자바 1장에 나옴

 

• public ScheduleResponseDto(Schedule schedule){}
  이거는 낮은 의존성 -> 높은 의존성이라 괜찮음

 

• ScheduleRequestDto scheduleRequestDto
  -> 변수 이름 그냥 req 이런 식으로 쓰는 게 더 가독성 좋음

 

• Pagination 구현할 때 스프링에서 제공하는 Page 사용하기

 

• 예외 처리할 때 cause 알 수 있도록 하기

 

• 이메일, 패스워드 검증은 리포지토리가 아니라 서비스에서 검증할 수 있도록 하기

 

• 3 layer architecture 말고도 4 layer architecture 등의 아키텍쳐가 있다.