Resolve "크론 잡 기능 개발" #47 - [merged] #100

Closed JuyeoungJun closed 3 years ago

In GitLab by @gm2202983 on Jun 16, 2021, 15:13

Merges feat/47-cron-job -> develop

What?

크론 서비스 기능 개발

Issue Number

47

Why?

크론 기능 구현을 위해

How?

API 스펙 참조

Testing?

CRUD 기능의 계층별 구현 및 테스트 후 통합테스트 진행

In GitLab by @gm2202983 on Jun 16, 2021, 15:15

changed the description

In GitLab by @gm2202983 on Jun 17, 2021, 10:17

changed title from Draft: Resolve "크론 잡 기능 개발" to Draft: Resolve "크론 잡 기능 개발"{+ #47+}

In GitLab by @gm2202983 on Jun 17, 2021, 10:17

changed the description

In GitLab by @gm2202983 on Jun 21, 2021, 13:16

added 16 commits

00633f90 - feat : 크론 서버 Repository 구현 및 테스트 + 테스트용 application.yml 작성
4d930621 - feat : Repository Layer return type를 Optional로 수정
41203499 - feat: Repository Layer 구현 및 테스트 완료
ba78c32d - chore : 레포지토리 리턴타입 일부 수정
fda566b6 - feat : Service Layer 구현 및 테스트 완료
5bbf1670 - chore: Repository 의 Save함수 리턴값을 uuid 에서 CronJob으로 변경
ac0df1ef - chore: uuid 서버 생성이 아닌 DB생성으로 변경사항 반영 및 SpringDataJPA style로 인터페이스 함수명, 파라미터, 리턴타입 변경 반영
82a19c2d - chore : Entity to Service 반영으로 인한 서비스계층 및 테스트 코드 수정
2e3a656a - chore: 서비스 계층의 리턴을 Entity 타입에서 DTO로 변경
5de9a79f - feat: Controller Layer 구현 및 테스트, Mapper 적용 완료
ceccefe9 - chore : 크론 잡 개발에 필요한 크론 서버 레포지토리 인터페이스 반영 및 일부 테스트 함수명 변경
bd660d7a - feat: 자바 객체를 json으로 변환하는 유틸 함수 생성
3bd2031e - chore : 코드스타일 적용 마무리
d2c8db82 - fix : 서비스 계층으로 전달할 파라미터가 빠져있던 부분 수정
bd5d2b47 - test : cron job 통합 테스트 추가
f04df494 - test : 통합 테스트 구현 완료

Compare with previous version

In GitLab by @gm2202983 on Jun 21, 2021, 13:57

added 1 commit

a64e6207 - style : 코드 스타일 정리 및 쓰지않는 import 삭제

Compare with previous version

In GitLab by @gm2202983 on Jun 21, 2021, 14:04

added 1 commit

3861a5ce - chore : test 모듈용 application.yml 삭제

Compare with previous version

In GitLab by @gm2202983 on Jun 21, 2021, 15:51

added 1 commit

aca03028 - chore : ci/cd 오류 해결을위한 테스트

Compare with previous version

In GitLab by @gm2202983 on Jun 22, 2021, 09:42

added 1 commit

a9080b7b - refactor : N + 1 문제 해결을 위한 fetch 조인 적용

Compare with previous version

In GitLab by @gm2202985 on Jun 22, 2021, 11:40

Commented on src/main/java/gabia/cronMonitoring/controller/CronJobController.java line 61

Delete에서만 ResponseEntity를 return 하는데 특별한 이유가 있으신가요?

In GitLab by @gm2202985 on Jun 22, 2021, 11:40

Commented on src/main/java/gabia/cronMonitoring/repositoryImpl/CronJobRepositoryImpl.java line 28

여기서 em.persist와 같이 em.merge도 동시에 하는 것은 어떤가요? https://velog.io/@kobongkyu/JPA-Merge-vs-Persist persist와 merge의 차이점입니다.

In GitLab by @gm2202985 on Jun 22, 2021, 11:40

Commented on src/main/java/gabia/cronMonitoring/service/CronJobService.java line 62

setter를 쓰지 않고 객체에서 메소드를 제공하는 방식은 어떤가요? https://velog.io/@aidenshin/%EB%82%B4%EA%B0%80-%EC%83%9D%EA%B0%81%ED%95%98%EB%8A%94-JPA-%EC%97%94%ED%8B%B0%ED%8B%B0-%EC%9E%91%EC%84%B1-%EC%9B%90%EC%B9%99

In GitLab by @gm2202981 on Jun 22, 2021, 12:10

Commented on src/main/java/gabia/cronMonitoring/repositoryImpl/CronJobRepositoryImpl.java line 57

리턴 타입이 Spring Data JPA의 컨벤션인 void와 차이가 나는데, 이 부분은 derived query문을 이용하고 @Modifying 어노테이션을 달면 정수형으로 삭제된 row 개수를 반환받을 수 있습니다. 해당 코드를 후에 Spring Data JPA로 대체해야 하는 상황이 발생한다면 조정해야 할 것으로 보입니다.

참고자료

In GitLab by @gm2202983 on Jun 22, 2021, 12:13

Commented on src/main/java/gabia/cronMonitoring/repositoryImpl/CronJobRepositoryImpl.java line 28

merge 함수를 일부러 사용하지 않았습니다. 이유는 다음과 같습니다.

요구된 기능 api에 put 메서드가 존재하지 않음.
사전 협의된 모든 수정은 patch 방식을 사용하기로 함.

혹시 모를 오류 상황으로 엔티티 정보에 null이 들어가는 put 방식의 merge 함수를 애초부터 사용하지 않아서

오류가 발생할 상황을 미리 막고자 합니다.

대신 서비스 계층에서 직접 set 하여 엔티티 수정 진행하도록 로직 작성했습니다.

In GitLab by @gm2202981 on Jun 22, 2021, 12:15

Commented on src/test/java/gabia/cronMonitoring/controller/CronJobControllerTest.java line 213

테스트 코드에서 API 스펙에 따른 HTTP 상태도 확인하는 것이 좋지 않을까요?

In GitLab by @gm2202983 on Jun 22, 2021, 12:20

Commented on src/main/java/gabia/cronMonitoring/service/CronJobService.java line 62

말씀해주신 엔티티의 생성자 혹은 create 메서드를 만드는 방법이 좋다고 생각하고 처음에 적용하려고 했으나 하지 않은 이유는 다음과 같습니다.

사전 협의 과정에서 개발 기간 동안은 setter를 이용하고 이후 리팩토링 과정을 통해 setter를 제거하기로 결정함.
크론 기능을 공동으로 개발하기에 공동으로 사용하는 엔티티에 [create 메서드 혹은 생성자] 를 만든다면, 혹은 setter를 없앤다면 머지 과정중 오류와 충돌이 예상됨.

따라서 개인적으로 만든 dto 객체들은 필요한 생성자를 자유롭게 선언/구현 해서 사용하고 있지만 엔티티 관련 부분은 setter 이외에 다른 방법을 사용하지 않았습니다.

이후 개발부터는 위 내용을 적용하겠습니다

In GitLab by @gm2202983 on Jun 22, 2021, 12:21

Commented on src/main/java/gabia/cronMonitoring/repositoryImpl/CronJobRepositoryImpl.java line 57

넵 확인했습니다 감사합니다!

In GitLab by @gm2202983 on Jun 22, 2021, 12:22

Commented on src/test/java/gabia/cronMonitoring/controller/CronJobControllerTest.java line 213

status().is4xxClientError()

함수를 이용해 큰 형태로 검사했는데 더 확실한 메서드를 사용해야 할까요? (ex, isSuccess(), isOk)

In GitLab by @gm2202983 on Jun 22, 2021, 12:25

Commented on src/main/java/gabia/cronMonitoring/controller/CronJobController.java line 61

현재 api 스펙에는 삭제시 상태코드 이외에 다른 값을 return 하지 않도록 정해져 있습니다.