feat: 유저의 멘토 지원서 신청 이력 조회 기능 추가 #603
Conversation
* refactor: long 타입을 Long 으로 수정
* test: MentorApplicationFixtureBuilder 에 rejectedReason 필드 및 빌더 메서드 추가
sukangpunch
requested review from
Gyuhyeok99,
Hexeong,
JAEHEE25,
lsy1307,
whqtker and
wibaek
as code owners
Walkthrough이번 변경사항은 멘토 지원서 이력 조회 기능을 구현하는 것입니다. 다음과 같이 구성됩니다:
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.java (1)
79-85: 엔드포인트 경로 설계 개선을 고려해보세요.기능은 정상적으로 작동하지만, 현재 경로 구조가 RESTful 설계 관점에서 다소 혼란스러울 수 있습니다.
현재:
/admin/mentor-applications/{site-user-id}/mentor-application-history
- 경로 상
mentor-applications리소스 하위에site-user-id가 위치하여, 특정 멘토 신청서의 하위 리소스처럼 보입니다.- 실제로는 특정 사용자의 전체 멘토 지원서 이력을 조회하는 기능입니다.
다음과 같은 대안을 고려해보세요:
/admin/site-users/{site-user-id}/mentor-application-history(리소스 중심)/admin/mentor-application-history/{site-user-id}(기능 중심)이는 설계 선호도의 문제이며, 팀 내 REST API 설계 가이드라인이 있다면 그에 따라 결정하시면 됩니다.
src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java (1)
91-110: 지원서 이력 조회 로직이 잘 구현되었으나, ID 사용의 일관성 개선이 필요합니다.전체적인 로직은 명확하고 올바르게 구현되었습니다:
- ✅ 유저 존재 여부 검증 (lines 92-93)
- ✅ 총 지원서 개수 조회 (line 95)
- ✅ 최신 5개 지원서 조회 (line 97)
- ✅ 지원서 순번 계산 로직 (
totalCount - index)이 정확합니다다만, line 95와 97에서 사용하는 ID가 일관되지 않습니다:
- Line 95:
siteUserId(파라미터, Long 타입) 사용- Line 97:
siteUser.getId()(엔티티의 ID, long 타입) 사용Line 92에서 이미
SiteUser엔티티를 조회했으므로, 두 repository 호출 모두siteUser.getId()를 사용하는 것이 더 일관되고 명확합니다.🔎 일관성 개선을 위한 제안
@Transactional(readOnly = true) public List<MentorApplicationHistoryResponse> findMentorApplicationHistory(Long siteUserId) { SiteUser siteUser = siteUserRepository.findById(siteUserId) .orElseThrow(() -> new CustomException(USER_NOT_FOUND)); - long totalCount = mentorApplicationRepository.countBySiteUserId(siteUserId); + long totalCount = mentorApplicationRepository.countBySiteUserId(siteUser.getId()); List<MentorApplication> mentorApplications = mentorApplicationRepository.findTop5BySiteUserIdOrderByCreatedAtDesc(siteUser.getId()); return IntStream.range(0, mentorApplications.size()) .mapToObj(index -> { MentorApplication app = mentorApplications.get(index); return new MentorApplicationHistoryResponse( app.getId(), app.getMentorApplicationStatus(), app.getRejectedReason(), app.getCreatedAt(), (int) totalCount - index ); }).toList(); }
📜 Review details
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.javasrc/main/java/com/example/solidconnection/admin/dto/MentorApplicationHistoryResponse.javasrc/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.javasrc/main/java/com/example/solidconnection/mentor/repository/MentorApplicationRepository.javasrc/main/resources/secretsrc/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixture.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixtureBuilder.java
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-11-17T06:30:49.502Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/dto/MentorApplicationRequest.java:10-23
Timestamp: 2025-11-17T06:30:49.502Z
Learning: MentorApplication 도메인에서 universityId는 null일 수 있으며, MentorApplicationRequest에서도 이 필드에 대한 NotNull validation을 추가하지 않아야 한다.
Applied to files:
src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixtureBuilder.javasrc/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixture.javasrc/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
📚 Learning: 2025-11-20T14:03:56.462Z
Learnt from: sukangpunch
Repo: solid-connection/solid-connect-server PR: 562
File: src/main/java/com/example/solidconnection/mentor/service/MentorMyPageService.java:76-93
Timestamp: 2025-11-20T14:03:56.462Z
Learning: MentorApplication의 universityId는 PENDING 상태에서는 null일 수 있지만, admin이 승인(APPROVED)할 때 반드시 대학 데이터를 생성하고 universityId를 채운 후 승인하므로, APPROVED 상태의 MentorApplication은 항상 non-null universityId를 가진다는 것이 비즈니스 규칙이다.
Applied to files:
src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixtureBuilder.javasrc/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.javasrc/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixture.javasrc/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java
🧬 Code graph analysis (1)
src/main/java/com/example/solidconnection/admin/dto/MentorApplicationHistoryResponse.java (1)
src/main/java/com/example/solidconnection/admin/dto/MentorApplicationResponse.java (1)
MentorApplicationResponse(7-20)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (9)
src/main/resources/secret (1)
1-1: 서브모듈 업데이트 - 상세 코드 리뷰 불가제공된 파일이 서브모듈 커밋 포인터 업데이트만 포함하고 있으므로, PR의 핵심 구현 코드에 대한 상세한 코드 리뷰를 진행할 수 없습니다.
다음 파일들이 리뷰에 필요합니다:
Controller 계층
AdminMentorApplicationController: 멘토 지원서 이력 조회 엔드포인트 구현Service 계층
AdminMentorApplicationService: 사이트 유저 유효성 검사, 총 신청 건수 조회, 상위 5개 항목 조회, DTO 매핑 로직Repository 계층
MentorApplicationRepository:findTop5BySiteUserIdOrderByCreatedAtDesc(),countBySiteUserId()쿼리 메서드DTO & Model
MentorApplicationHistoryResponse: 응답 구조 및 필드 정의테스트
AdminMentorApplicationServiceTest: 정렬, 제한, 빈 이력, 필드 검증, 존재하지 않는 유저 처리이 실제 구현 파일들이 포함된 전체 코드 리뷰를 요청드립니다.
src/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixture.java (1)
21-21: 거절 사유 상수 추가가 깔끔합니다.테스트에서 사용할 거절 사유를 상수로 정의하여 fixture에서 일관되게 사용하고 있어 좋습니다. 테스트 데이터의 일관성이 확보되었습니다.
Also applies to: 68-68
src/test/java/com/example/solidconnection/mentor/fixture/MentorApplicationFixtureBuilder.java (1)
24-24: Fixture 빌더 확장이 잘 구현되었습니다.
rejectedReason필드와 빌더 메서드가 기존 패턴과 일관되게 추가되었고,create()메서드에서 null 체크 후 reflection으로 값을 설정하는 방식도 적절합니다. 테스트 목적의 reflection 사용은 합당합니다.Also applies to: 62-65, 88-90
src/main/java/com/example/solidconnection/admin/dto/MentorApplicationHistoryResponse.java (1)
6-12: 이력 조회용 DTO 설계가 간결하고 적절합니다.멘토 지원서 이력 조회에 필요한 핵심 정보만 포함하여 깔끔합니다.
applicationOrder필드를 통해 전체 지원 순서를 파악할 수 있도록 한 점이 좋습니다. 기존MentorApplicationResponse보다 단순화된 구조로 용도에 맞게 설계되었습니다.src/main/java/com/example/solidconnection/admin/controller/AdminMentorApplicationController.java (1)
79-85: 사용자 존재 여부 검증이 서비스 레이어에서 처리되고 있습니다.컨트롤러에서 별도로
siteUserId검증을 하지 않지만, 테스트 코드(Line 611-613)를 확인한 결과 서비스 레이어에서USER_NOT_FOUND예외를 던지고 있어 적절하게 처리되고 있습니다.src/test/java/com/example/solidconnection/admin/service/AdminMentorApplicationServiceTest.java (1)
515-615: 멘토 지원서 이력 조회 테스트가 매우 포괄적입니다.새로운 이력 조회 기능에 대한 테스트가 다음 시나리오를 모두 커버하고 있어 훌륭합니다:
기본 이력 조회 및 정렬 검증 (Lines 519-540)
- 최신 생성 내림차순 정렬 확인
- applicationOrder 필드 검증
5개 제한 검증 (Lines 543-568)
- 7개 생성 시 최신 5개만 반환되는지 확인
빈 이력 처리 (Lines 571-580)
- 지원서가 없을 때 빈 리스트 반환
응답 필드 검증 (Lines 583-603)
- 상태값과 거절 사유가 올바르게 포함되는지 확인
에러 처리 (Lines 606-614)
- 존재하지 않는 사용자 조회 시 예외 발생 검증
applicationOrder가 반환된 목록 내 순위가 아닌 전체 지원 이력에서의 순서를 나타내는 점도 잘 검증되었습니다.src/main/java/com/example/solidconnection/admin/service/AdminMentorApplicationService.java (2)
33-33: 새로운 의존성 주입이 적절합니다.유저 존재 여부 검증을 위해
SiteUserRepository가 추가되었습니다. 새로 추가된 히스토리 조회 기능에 필요한 의존성이며, 기존 패턴과 일관되게 구성되어 있습니다.
52-55: 파라미터 타입 변경은 호환성 문제가 없습니다.검토 결과:
메서드 구현:
rejectMentorApplication(Long mentorApplicationId, ...)파라미터는 이미 박싱된Long타입입니다.호출 지점 확인:
- 컨트롤러에서는
@PathVariable("mentor-application-id") Long mentorApplicationId로 받은Long타입을 그대로 전달합니다.- 테스트에서는 원시
long타입을 사용하나, Java의 오토박싱이 자동으로Long으로 변환합니다.결론: 모든 호출자가 이미 호환되어 있으므로 추가 조정은 필요하지 않습니다.
src/main/java/com/example/solidconnection/mentor/repository/MentorApplicationRepository.java (1)
18-20: 새로운 쿼리 메서드 구현이 완벽합니다.추가된 두 메서드는 Spring Data JPA 3.1.5의 query derivation 규칙을 정확하게 따르고 있습니다:
findTop5BySiteUserIdOrderByCreatedAtDesc
- 생성일 기준 내림차순으로 상위 5개를 조회하는 명확한 의도
countBySiteUserId
- 특정 유저의 지원서 총 개수를 카운트
기존 메서드들과 동일하게 primitive
long타입을 사용하여 코드의 일관성도 잘 유지되고 있습니다.
1 participant
관련 이슈
작업 내용
특이 사항
MentorApplicationHistoryResponse 의 applicationOrder 부분은
"N차 멘토 신청" 에서 N 부분을 나타내었습니다.
리뷰 요구사항 (선택)
현재 데이터를 조회 할 때, 지원서 생성 시간 기준으로 내림차순 조회 및 5개 limit 을 걸고 조회를 합니다.
생성 시간 기준 내림차순으로 조회해서 가져오는 부분은 스스로 판단한 부분인데 혹시 더 좋은 방법이나, 해당 방식에 어색함이 있다면 수정하거나 다시 명확한 기획을 요청 드리겠습니다!