#334 냉장고 관련 API 클린코드 및 동적쿼리 적용

[psyeon1120]

📍 이슈 번호

• [refactor] Fridge 클린 코드 적용 및 성능 개선 #334

🛠️ 작업 내용

1. 냉장고 삭제에서 cascade 처리가 되어있음에도 불구하고 관련 데이터들을 삭제하는 로직이 있어서 수정했습니다.
2. 조건마다 달랐던 조회 API를 냉장고 식품 조회로 통합했습니다. 페이징 처리도 추가했습니다.
3. FridgeFood는 기존에 유통기한(일자)가 shelfLife였습니다. 남은 일수를 추가하면서 용어를 조금 바꿨습니다. 영어로는 shelfLife가 남은 일수 느낌이더라구요.
   • 유통기한(일자): expirationDate(LocalDate)
   • 남은 일수: shelfLife(int)
4. 냉장고 탈퇴 API 코드 정리
5. 냉장고 식품 상세조회 API 코드 정리
6. 내 냉장고 조회 API 반환 형태 변경. 이제 냉장고는 한 사람당 한개이기 때문에, 로그인을 했을 때 이 API를 호출해서 냉장고가 있으면 id와 냉장고 이름을 받을 수 있도록 했습니다. 없으면 null을 반환해요.
7. 냉장고 정보 조회 API 반환형태 변경 및 코드정리
8. 냉장고 멤버 목록 조회 API 반환형태 변경

🎸 기타 사항

1. 서비스 단에서 user, fridge, fridgeUser 등을 너무 다 검사하는 게 굳이 필요할까 싶어서 한번 줄여봤는데 어떻게 생각하시나요? 포괄적으로 하나만 검사해서 오류를 뱉어도 되는지, 아니면 하나씩 단계별로 검사해서 오류를 뱉는 게 더 적절한 지?
   • 전
     

     IceButler_Server/src/main/java/com/example/icebutler_server/fridge/service/FridgeServiceImpl.java

     Lines 197 to 204 in 223e014

     	public FridgeFoodRes getFridgeFood(Long fridgeId, Long fridgeFoodId, Long userId) {
     	User user = userRepository.findByIdAndIsEnable(userId, true).orElseThrow(() -> new BaseException(NOT_FOUND_USER));
     	Fridge fridge = fridgeRepository.findByIdAndIsEnable(fridgeId, true).orElseThrow(() -> new BaseException(NOT_FOUND_FRIDGE));
     	fridgeUserRepository.findByUserAndFridgeAndIsEnable(user, fridge, true).orElseThrow(() -> new BaseException(NO_PERMISSION));
     	FridgeFood fridgeFood = fridgeFoodRepository.findByIdAndFridgeAndIsEnable(fridgeFoodId, fridge, true).orElseThrow(() -> new BaseException(NOT_FOUND_FRIDGE_FOOD));
     	return FridgeFoodRes.toDto(fridgeFood);
     	}

   • 후
     

     IceButler_Server/src/main/java/com/example/icebutler_server/fridge/service/FridgeServiceImpl.java

     Lines 168 to 171 in 04fa955

     	public Page<FridgeFoodsRes> searchFridgeFoods(Long fridgeId, Long userId, String word, String category, Pageable p) {
     	fridgeUserRepository.findByFridgeIdAndUserIdAndIsEnable(fridgeId, userId, true).orElseThrow(() -> new BaseException(NOT_FOUND_FRIDGE_USER));
     	return fridgeFoodRepository.searchFridgeFoods(fridgeId, word, category, p);
     	}

   • 요렇게 @Auth어노테이션에서 경우별로 처리하는 방법도 있는 것 같아요!
   • 음 근데 하나로 줄이면 FRIDGE_USER_NOT_FOUND가 아니라 NO_PERMISSION이려나요?
2. 정렬한 곳도 많이 있으니까 코드 볼 때는 꼭 whiteSpace 무시하는 설정으로 봐주세요!

[sojungpp]

고생하셨습니답 !! 냉장고 부분 복잡했을텐데 동적쿼리로 복잡한 로직들 합쳐지고 사소한 변수명 변경도 이전보다 훨씬 알기 쉬워진 것 같아요 😸

로직 이해하느라 찾아보다가 해당 함수를 확인했는데, 이 부분 파라미터가 이제 expirationDate 의미인 것 같은데 맞다면 파라미터명도 변경하는 것 어떤가요 ?!

IceButler_Server/src/main/java/com/example/icebutler_server/global/util/FridgeUtils.java

Lines 6 to 9 in 223e014

	public abstract class FridgeUtils {
	public static int calShelfLife(LocalDate shelfLife) {
	return (int) (-1 * ChronoUnit.DAYS.between(LocalDate.now(), shelfLife));
	}

[sojungpp]

변수명 바꾼 거 직관적이라 넘 좋으네요 마음이 편안 😌

[sojungpp]

합친 거 너무 깔끔한 것 같아요 최고.

[sojungpp]

포괄적으로 하나만 검사해서 오류를 뱉어도 되는지, 아니면 하나씩 단계별로 검사해서 오류를 뱉는 게 더 적절한 지?

저는 개인적으로 할 수 있는 한 서버에서 많은 예외처리를 진행하는 게 (실제 운영을 한다면) 안정적인 운영을 할 수 있어서 중요하다고 생각하는 편입니다..! 만약, 해당 로직에서 오류가 발생하면 user가 문제인지/fridge가 문제인지/fridgeUser가 문제인지 추가적인 테스트없이 바로 로그 확인해서 의심되는 관련 로직을 확인하고 수정할 수 있으니까요!
그래서 전자를 더 선호하는 편입니다. (User는 로그인 리졸버를 통해 체크하니까 객체가 필요없으니 제외하고, 제안하신 것처럼 userId로만 검사해도 좋을 것 같네요!)
혹시 후자를 선호하는 이유도 말씀해주실 수 있나요 ?! 어떤 방법이 좋을지 같이 생각해보아요 -

스프링 인터셉터 사용해서 체크하는 레퍼런스 너무 잘 봤습니다 !! 덕분에 읽어보면서 공부해보려고 합니다 흐 저희 로직 중에서도 ROLE을 통해 체크하는 API가 있으면 활용하면 좋을 것 같네요! 리팩토링하면서 찾아보겠습니답 혹시 좋은 아이디어 있으면 공유하겠습니다 - !

[psyeon1120]

포괄적으로 하나만 검사해서 오류를 뱉어도 되는지, 아니면 하나씩 단계별로 검사해서 오류를 뱉는 게 더 적절한 지?

혹시 후자를 선호하는 이유도 말씀해주실 수 있나요 ?! 어떤 방법이 좋을지 같이 생각해보아요 -

사용자 입장에서는 냉장고가 없어도, 냉장고 멤버가 아니여도 결국 접근을 못하는 건 똑같은데, 쿼리를 이것저것 다 날리는게 적절한 방법은 아니라고 생각했습니다! 물론 개발자 입장에서는 모든 예외사항을 다 뱉는 것이 편하긴 하겠지요?
(사실 코드 중복이 신경쓰이고 귀찮은건 안비밀,,,이지만 다시 생각해보니 다 검사하긴 해야할 것 같아요...ㅎㅎ)

추가로 저런식으로 확인만 하고 해당 객체가 필요없을 때는 findBy보다는 exist로 존재 유무만 확인하는 건 어떤가요?? 속도면에서 조금은 더 이득이 있을 것 같습니다!

[sojungpp]

추가로 저런식으로 확인만 하고 해당 객체가 필요없을 때는 findBy보다는 exist로 존재 유무만 확인하는 건 어떤가요?? 속도면에서 조금은 더 이득이 있을 것 같습니다!

옹 exists로 확인하는 거 좋습니다 !! 중복 인정이오 .. 그러면 exists로 확인 + 중복되는 코드 별도 private 메서드로 분리해서 중복 줄이기는 어떤가욥 !

[psyeon1120]

옹 exists로 확인하는 거 좋습니다 !! 중복 인정이오 .. 그러면 exists로 확인 + 중복되는 코드 별도 private 메서드로 분리해서 중복 줄이기는 어떤가욥 !

네! 일단 머지하고 나중에 이슈 새로 만들어서 해보겠습니당