오늘부터는 드디어 V2 구조 개선 작업이 시작되었다!
V2에서는 구조 개선과 조회 품질 튜닝, 개발 서버 배포와 테스트를 요구하고 있는데, 나는 이 중에서 구조 개선을 맡았다!
구조 개선과 함께,, 어제 코드 리뷰를 통해 피드백 받았던 부분들을 반영하며 리팩토링하는 작업을 진행했다.
우선은 우리가 작성한 API URL이 의미가 불명확하거나 통일되지 않은 형식이 많이 있었다.
그래서 RESTful API라는 설계 원칙에 맞게, 이 API만 보고 어떤 자원을 어떤 기준으로 사용할지를 명확하게 보여줄 수 있는 방향으로 수정해보았다.
이와 함께 동일한 도메인을 사용하는 패키지를 하나로 통합하고, 이 과정에서 같은 내용을 반환하는 메서드는 DTO를 통합해주는 작업을 진행했다.
우리는 request dto와 response dto를 담는 패키지를 model이라고 명명하였는데, 사실 model은 의미가 추상적일 뿐더러 dto와 vo 모든 내용들을 포함하는 경우에 많이 사용한다고 한다.
하지만, 우리는 dto를 담기 위해 해당 패키지를 사용하기 때문에, 이 패키지 이름을 dto로 바꾸었다.
그런데.. 패키지의 이름 하나 바꾸고, 패키지 위치 하나 바꾸는데, 함께 수정해야 할 내용들이 어마어마하게 많더라.
그 과정 중에 DTO 프로젝션을 사용하는 곳에서 에러가 생기기도 했다.
이전에 개인 프로젝트를 진행할 때 패키지 구조 변경을 함부로 진행하는 것이 아니라고 피드백을 받았었는데, 그 이유를 오늘 확실히 느낄 수 있었다.
이후에는 로직들을 수정해나가기 시작했는데, 우선은 ExceptionHandler에 다룰 예외 클래스들을 추가하였다.
기존에는 CustomException이나 Valid에서 발생하는 예외만을 다루고 있었고, 그 외의 예외들은 스프링의 기본 핸들러를 통해 처리되도록 구현했었다.
그런데, 오늘은 이 예외 클래스들 외에도 우리 서비스에서 발생할 수 있는 예외 클래스들에 대한 핸들러를 추가했고, 최후의 수단으로 RuntimeException 클래스에 대한 예외 핸들러를 추가해두었다.
이렇게 우리 서비스에서 나타날 수 있는 웬만한 예외들을 처리할 수 있었다.
이 외에도 Objects.equals를 ObjectUtils.nullSafeEquals로 바꾼다던가, 엔티티 객체의 상태 확인을 위한 내부 메서드를 생성하는 등의 작업을 진행했다.
그리고, 어제 발견한 스케줄러의 허점이 있었는데, 어플리케이션 재시작 시 스케줄 복구 로직에 대한 문제였다.
기존에는 COMPLETED 되지 않은 모임들에 대해서만 스케줄을 다시 복구했는데, 사실 모임이 COMPLETED 된 후 3시간 뒤에 후기 작성 알림이 발송된다.
그래서 이 사이에 어플리케이션이 재시작 된다면, 이 알림에 대한 내용은 복구할 수 없게 된다.
@Override
public List<Meeting> findActivateMeetingsForNotification(LocalDateTime startDate, LocalDateTime endDate) {
return queryFactory
.selectFrom(meeting)
.leftJoin(notification).on(
notification.meeting.id.eq(meeting.id),
notification.type.eq(NotificationType.COMMENT_REQUESTED)
)
.where(
meeting.status.eq(MeetingStatus.COMPLETED),
meeting.isDeleted.isFalse(),
notification.id.isNull(),
meeting.meetingDateTime.between(startDate, endDate)
)
.fetch();
}
그래서 오늘은 열심히 COMPLETED 되었지만, 알림이 생성되지 않은 모임들을 찾도록 쿼리문을 작성했다.
이렇게 meeting과 notification 테이블을 매핑하고, notification의 값이 null인 meeting만 찾도록 조건을 걸어두었다.
그런데, 이때 모임 일시를 어제 ~ 오늘 기간으로만 설정하였다.
모임의 후기 작성에 대한 알림인 만큼 일주일 전에 있었던 모임에 대한 후기를 오늘 와서야 작성하라고 알림이 오면, 사용자 입장에서 좋지는 않을 것 같았기 때문이다.
이걸 마지막으로 v1에 대한 리팩토링은 모두 마무리하였다.
내일부터는 v3 고도화 작업에서 어떤 내용들을 추가할 것이고, 무엇을 어떻게 구현할 것인지 자료 조사를 진행할 예정이다.
우리 팀이 작성한 코드는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
오늘은 하루 종일 코드 리팩토링을 진행했는데, 항상 작업할 때는 이게 최선이라고 생각하고 작업을 하지만, 다시 보면 수정할 내용들이 계속 계속 생긴다.
앞으로는 한 번 작성할 때 여러번 생각하면서 작성해봐야겠다.